Complete rebuild of build system

[eitsupi]

• Stop using python-semantic-release (See chore: bump prql-python from 0.9.0 to 0.10.0 #283 (comment))
• Stop using poetry (See chore: update Python and poetry #270 (comment))

[max-sixty]

I rather like poetry! But I don't have a strong preference if you do. What's the alternative? (I don't think that plain pip is fun, because it can't generate a lockfile).

[eitsupi]

What about pdm or pip-tools?
(Honestly, I don't understand the importance of "lock file" here. Because it has nothing to do with the user.)

[max-sixty]

What about pdm or pip-tools?

I just checked out PDM, looks interesting. I don't know it well. IME pip-tools is OK but a worse version of poetry...

But does poetry have a downside? It's not perfect, but it has served me very well over the past few years. It it so much easier than before it arrived... If you have a strong view for PDM then I'm open to moving.

The current break on python 3.12 is that greenlet package. poetry will tell us where that comes from, I can have a look.

the importance of "lock file" here

The biggest impact of a lock file in python is fixed dependencies when developing and testing. Over at xarray (where I first started doing more serious open-source work), we use conda. And it's quite inconvenient, because our tests on main will break when a dependency changes, and we have to rush to fix it. We have some strategies for managing that, such as testing against the main branch of some of our dependencies, but it's not ideal. A lock file makes that process deliberate — only upgrade each dependency when we're ready, without breaking tests on main. (I also agree that it doesn't affect the user, there's no equivalent cargo binary distribution)

Does that make sense?

[max-sixty]

(one benefit of poetry is that it works with dependabot; I'm not sure whether the others do?)

[eitsupi]

Recently CI suddenly started failing, apparently due to the fact that they had previously installed the latest jupysql 0.10 and now they have 0.7 installed and that is why it is failing.

Looking at the differences in the lock file, it appears that jupysql 0.7.2 was added by #286.
I do not know what poetry intended to do with these changes...

How about moving to Hatch? https://github.com/pypa/hatch
Isn't the fact that pypa is doing the development a reason to choose that?

[max-sixty]

I do not know what poetry intended to do with these changes...

+1, quite confusing. FWIW I haven't had this before with poetry, but this did seem bad.

How about moving to Hatch? https://github.com/pypa/hatch

I'm open to it! If you think it's better, I'm fine to move.

It does look like a well-managed project.

One downside is losing dependabot. But possibly they'll make dependabot compatibility in the future.

[eitsupi]

@max-sixty I think you made a mistake merging #429 as a fix, #429 is not a fix.

I'm really tired of using the bizarre build system of this repository, where we can't release correctly if we get the PR title wrong, and poetry just seems to complicate the dependency issue.

[eitsupi]

Some thoughts:

• Use uv instead of poetry
• Restrict PR titles with GitHub Actions to prevent merging of incorrect titles

[max-sixty]

Sorry this is falling on you — I apologize for my part. I also agree that people are liable (at least me!) to get the prefix wrong.

Keen to move to uv. I would have waited to for dependabot to have uv support, but I'm happy to move to uv beforehand if you would like to.

[eitsupi]

Ok, let's move to uv.
Dependabot will support uv in next few months.
Ref: github/roadmap#1100

[max-sixty]

OK great!