No joke! This is only maybe the third incarnation of python packages or so, if you count bdist_egg’s. (Not all bad for having been around this long. In 2012, Armin was not far off in writing http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/ – we’re a little better off these days than we were then, thanks to support for pre-compiled packages.)
I’ve been living in setuptools/wheels for the last two weeks for work. It’s not totally awful but the lack of cohesiveness between all these tools is kind of annoying.
I still haven’t figured out a way to integrate this into a CI system and tag metadata as part of the CI build process while creating a wheel package. pip wheel or setup.py bdist_wheel will helpfully run setup.py build & egg_info for you as part of the wheel building process, but I haven’t found any way to make it actually pass arguments to either of those. :(
Also figuring out how to include non-python resources in a package is kind of a nightmare. pkg_resources? MANIFEST.in? Also SURPRISE, setuptools/wheels totally ignores MANIFEST.in unless you pass include_package_data=True in setup(). THAT one took me a couple days to find.
No. The package managers of distributions have many disadvantages, the biggest one being the missing support for virtualenvs. Deployment of Python code is so much easier when you completely ignore the distribution’s package mangement. Python Wheels are also cross platform (as long as they’re pure Python packages), Windows and OS X included.
Nix actually solves these problems quite well and even better because it can have packages from any language. It’s a shame that we have developers spending more time on yet another Python package manager (and every language community is doing this, even Ocaml, my preferred language) rather than banding together and using a package manager that solves the problem once and for all for everyon.
I think it’s safe to assume that the effort involved in getting Nix to work on Windows is less than the effort involved in every programming langauge getting its own package manager that has to run on all the same platforms.
But it doesn’t have to be Nix, I just want everything in the same manager.
No. The package managers of distributions have many disadvantages, the biggest one being the missing support for virtualenvs.
This is not a fundamental problem of packaging. It is maybe a problem of those systems (at least deb and rpm) being quite old and far from perfect. That doesn’t mean that packaging has to be solved for each and every single technology (pip, gems, melpa, cpan, ctan, opam, hex, npm, mvn, hackage, … ad infinitum).
All those are versions of each others, and all of those share good things and bad things that are specific to packaging, not languages.
As mentioned repeatedly here in lobsters, it seems to me that nix solves most, if not all, of the issues one can find when using deb or rpm in a generic way. Even if it didn’t I still can’t see a good reason to invest in solving the packaging problem specifically for every language.
Please tell me the name is an in joke recognizing this is like the 53rd time somebody has reinvented packaging.
No joke! This is only maybe the third incarnation of python packages or so, if you count bdist_egg’s. (Not all bad for having been around this long. In 2012, Armin was not far off in writing http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/ – we’re a little better off these days than we were then, thanks to support for pre-compiled packages.)
I’ve been living in setuptools/wheels for the last two weeks for work. It’s not totally awful but the lack of cohesiveness between all these tools is kind of annoying.
I still haven’t figured out a way to integrate this into a CI system and tag metadata as part of the CI build process while creating a wheel package. pip wheel or setup.py bdist_wheel will helpfully run setup.py build & egg_info for you as part of the wheel building process, but I haven’t found any way to make it actually pass arguments to either of those. :(
Also figuring out how to include non-python resources in a package is kind of a nightmare. pkg_resources? MANIFEST.in? Also SURPRISE, setuptools/wheels totally ignores MANIFEST.in unless you pass include_package_data=True in setup(). THAT one took me a couple days to find.
I found this the other day too: https://bitbucket.org/pypa/wheel/issues/99/cannot-exclude-directory No clue why it hasn’t been fixed yet.
Can we please get rid of these language specific package managers??
No. The package managers of distributions have many disadvantages, the biggest one being the missing support for virtualenvs. Deployment of Python code is so much easier when you completely ignore the distribution’s package mangement. Python Wheels are also cross platform (as long as they’re pure Python packages), Windows and OS X included.
Nix actually solves these problems quite well and even better because it can have packages from any language. It’s a shame that we have developers spending more time on yet another Python package manager (and every language community is doing this, even Ocaml, my preferred language) rather than banding together and using a package manager that solves the problem once and for all for everyon.
Nix doesn’t seem to support Windows, so there is one big use case that it doesn’t solve.
I think it’s safe to assume that the effort involved in getting Nix to work on Windows is less than the effort involved in every programming langauge getting its own package manager that has to run on all the same platforms.
But it doesn’t have to be Nix, I just want everything in the same manager.
[Comment removed by author]
This is not a fundamental problem of packaging. It is maybe a problem of those systems (at least deb and rpm) being quite old and far from perfect. That doesn’t mean that packaging has to be solved for each and every single technology (pip, gems, melpa, cpan, ctan, opam, hex, npm, mvn, hackage, … ad infinitum).
All those are versions of each others, and all of those share good things and bad things that are specific to packaging, not languages.
As mentioned repeatedly here in lobsters, it seems to me that nix solves most, if not all, of the issues one can find when using deb or rpm in a generic way. Even if it didn’t I still can’t see a good reason to invest in solving the packaging problem specifically for every language.
Hell, I’d settle for not requiring packages at runtime. Preferably not in a way that also has an entire OS tag along.