Update PyPI Package
sseshan7 opened this issue · 8 comments
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?
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:
- Command line usage instructions and help for the various tasks.
This is something I can work on.
Rel issue: #188
cc: @illegalnumbers
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.
It has been pushed to the main pypi directory: https://pypi.org/project/united-states-congress/ by @illegalnumbers
What actions do you need to take to make this happen?
For us to update the united-states-congress package we need @illegalnumbers to hand over the maintainership of the pypi package over to you or me (or @JoshData assuming he wants to maintain the pypi package see prev comments)
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 unitedstates/congress to "support" such a pypi package, @JoshData would have to write off on a PR that adds installing from pypi as an alternate or recommended install method (again concerns on maintainership burden arise)
Does every commit to the master branch constitute the version incrementing?
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.
Command line usage instructions and help for the various tasks.
This is def a good one, but I think is orthogonal to a release on pypi.
A previous suggestion by you:
One side-effect however, when I call usc-run from somewhere other than the repo root, it creates the data/ and cache/ dirs in the directory where I called it. I feel like this is undesirable, and it should always download to some default location unless a download destination is provided.
This is another good issue that can be solved with the XDG spec, specifically $XDG_CACHE_HOME/usc for cache/. For data/ as that is an output I think default should be current directory and user should be able to specify output data/ dir with a flag like --data-output Again tho, it should be its own issue from this.
I believe the closure of this issue would be accomplished with decision of adding pip install united-states-congress on the README.md or not.
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.
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.