为不同的python版本准备Pypi包

Question

I'm preparing a package for Pypi that calculates the steady-state distributions for Markov chains with discrete state spaces .

The main files with code run without problems both on Python 2.7 and Python 3.5 (tested this in a virtual environment). The setup.py file also seems to work, at least for Python 2.7.

From this point on it is unclear to me how to proceed. Should I run setup.py on all possible version of Python to create separate 'egg' files for each Python version? That seems rather tedious, considering the file runs on both Python versions anyway, and you'd have to redo this every time you update a package.

What would be good practice here?

Answer 1

If you're looking for a good release checklist (answering the question "what should I do before I push to pypi?"), you can't go past Audrey Roy's PyPI Release Checklist . That's a living document, and is updated as needed, but the high points are:

• Update your changelog
• Update your version number
• Run your tests
• Build for pypi, using both source distributions (sdist) and the newer wheel format.
• Push to the pypi test instance (using twine )
• Check that your README render correctly
• Test that installations from the test instance work
• Push to pypi production
• Update the git repository tags/releases

Other less important thing may include:

• Run a python style checker like pycodestyle or flake8
• Generate test coverage

With respect to the element of the question about eggs - they are no longer necessary (since the wheel format was introduced). Consider adding something to your .gitignore file to prevent them from being added to your repository. Basically, unless you use native code, all you need to do is deploy both sdists and wheels, and you should be fine.

With respect to "running without problems" consider converting your examples to tests, and then running those tests as part of every release. You can either use tox locally, or use a service like travis or appveyor . This is particularly important if you have behaviour that should be preserved between releases - this is an important part of semantic versioning