Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete rebuild of build system #284

Open
2 tasks
eitsupi opened this issue Oct 27, 2023 · 9 comments
Open
2 tasks

Complete rebuild of build system #284

eitsupi opened this issue Oct 27, 2023 · 9 comments

Comments

@eitsupi
Copy link
Member

eitsupi commented Oct 27, 2023

@max-sixty
Copy link
Member

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
Copy link
Member Author

eitsupi commented Oct 28, 2023

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
Copy link
Member

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
Copy link
Member

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

@eitsupi
Copy link
Member Author

eitsupi commented Nov 15, 2023

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
Copy link
Member

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
Copy link
Member Author

eitsupi commented Oct 14, 2024

@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
Copy link
Member Author

eitsupi commented Oct 14, 2024

Some thoughts:

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

@max-sixty
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants