3 ms·
Support for local, per-project installs without hacks like virtualenv. Per-project configurations to map things like external dependencies and project info. Se
by EvanPlaice 11y ago
Support for local, per-project installs without hacks like virtualenv.
Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer.
Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary.
Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain.
Support for Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard
Standard support for direct install from GitHub without weird hacks.
Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck.
Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package.
Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to
publish a package and the package manager 'just works'.
- crdoconnor 11y ago* Virtualenv isn't a hack. * Setup.py/MANIFEST.in seems like a pretty clear answer to me. * I've worked with python for about 10 years and only once have I come across two packages that required conflicting versions that I wanted to deploy in the same environment. * Yes, I do it pretty frequently. * "MD os the defacto standard" Huh? According to whom? ReST is fine. * "Standard support for direct install from GitHub without weird hacks." - stick "git+https://github.com/yourname/yourpackage" https://github.com/yourname/yourpackage" in your requirements.txt and off you go. * Yeah, they should really standardize on pip, but this is relatively minor. * Use one of the templates. * Yes, I hear somebody even published a package that checked if a number was negative. And it had a bug.