-
Notifications
You must be signed in to change notification settings - Fork 204
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
Update PyPI Package #282
Comments
One question I have is regarding versioning. @acxz Does every commit to the master branch constitute the version incrementing? |
One thing I'd want to see merged before releasing:
This is something I can work on. |
Rel issue: #188 cc: @illegalnumbers
It has been pushed to the main
For us to update the If @illegalnumbers is unresponsive, filing a support ticket at https://github.com/pypa/pypi-support under PEP 514, allows us to reclaim the unmaintained package. With this we can upload a newer version of the codebase. All of this does not require any commits to this repo. However, for
As of now the version is fixed no matter commit changes. While semantic versioning has been mentioned, @Andrew-Chen-Wang's suggestion of date versioning makes the most sense. I think the best approach to version and releasing to pypi would be "code dumps", i.e. when things look good enough just make a commit for the version change in setup.py and a tag on github releases with the date version then upload to pypi. (again maintainership burden) Notwithstanding that, just a simple point release scheme is good enough (as long as we don't exceed the current data, which I doubt will happen, so that we can fallback to the date versioning scheme whenever the project wants.
This is def a good one, but I think is orthogonal to a release on pypi. A previous suggestion by you:
This is another good issue that can be solved with the XDG spec, specifically I believe the closure of this issue would be accomplished with decision of adding |
I've found that sharing of maintainership on PyPi is great, but I also recommend a GitHub workflow that creates a PyPi release when a maintainer releases a GitHub release. This helps when there's a team of maintainers who don't have much down time. |
Great suggestion, such a change would be required for the closure of this issue if @JoshData is willing to support it. Again maintainership burden |
@acxz Just a note but for an auto release bot that releases everyday, you can take a look at the auto changelog and release bot at cookiecutter django for inspiration (or copy pasta). Though I think it would be pretty annoying to release every day |
I do not recommend a release everyday at all. I don't this project undergoes that many changes to warrant such sophisticated methods. |
Agreed. Please do not make a release every day. |
Hi @JoshData,
I am interested in finishing the work @acxz did with getting this repo ready for python packaging in #267. I would like to push the latest repo to PyPI to allow users to install via pip.
The last time the package was updated was in 2016: https://test.pypi.org/project/united-states-congress/. I think this is a good time to release the repo to PyPI for people to use. The repo now has an easy to use command to run tasks from the command line, and the repo's modules can be imported in the REPL and other scripts users would like to write.
I have tested the workflow by packaging this repo locally and uploading it to test.pypi.org, and was able to install it successfully install and run it as well on my machine.
I am interested in maintaining this python package along with @acxz. What What actions do you need to take to make this happen? Do you have any suggestions about going about this?
The text was updated successfully, but these errors were encountered: