-
Notifications
You must be signed in to change notification settings - Fork 75
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
Migration to pyproject.toml? #186
Comments
This looks like a good idea (thanks for sharing the PEP). I’d love some help on this as I’ve not used this system before. |
Great. I'll propose a PR asap. |
Question: how do you tag a release? Do you use bum2version, or something similar? Or do you just add a tag to the repo? From what I see, I'd say you manually add a tag to the repo and let setuptools find the version. Is that true? If so, Would you mind to change the tagging procedure? It would make things more declarative..., more straightforward, and easier for the migration, I'd say |
Thanks for sharing this tool. I do currently tag releases, and use semantic versioning to build version numbers for test packages. The CI releases package builds to test-pypi and pypi using these versions, and stable builds are only pushed on new tags. I do like the current system, but could be convinced to change. However, I don't quite see why a different system is necessary, as development happens under VCS, and released versions contain explicit semantic version strings already. |
Preparing the PR for the transition to I try to explain it here and also what I would do. It's just my observations and opinion, I don't pretend to impose anything. Also it is not a big thing after all... From PEP 621, it is clearly advisable to use a static version number in the project. Right now the version in That has at least two negative side effects:
For point 1, of course I think we agree in the importance of distinguishing between development and runtime dependencies. In my opinion point 2 is also a problem to be addressed: it would be very good if the In short, my suggestion would be:
I'll make a PR to show you something concrete, and you let me know... unless you think this is a no-go option. |
Hey @palao. I still need to take some time to digest this so thanks for your patience! |
It is totally fine to use dynamic version numbers, you just need to remember to write (You may have misread PEP 621: The section above the version number describes the package name, which indeed must be statically defined.) To be honest, as much as I look forward to defining metadata in a standardized way in |
Hi, again.
The current best practices in the python community is to use a static source of metadata for a project in a
pyproject.toml
file instead of usingsetup.py
(even in combination withsetup.cfg
), see PEP 621.Is this something to be considered for this project? If yes, I offer a hand: I can make a PR...
PS notice that it has no impact on the end users that
pip install
the project. It's mostly relevant for developers. But I think it is a good thing to have.The text was updated successfully, but these errors were encountered: