One way out of these bad practices is perhaps making use of either GNU Guix ([1]) --- which is a package manager that has roll-backs, aims for reproducible builds, avoids bundling and empowers the end-user because it can be used even in non-root, besides it can be installed in any system distribution that has most basic tools from the GNU project --- or GuixSD ([1]) --- a system distribution which uses GNU Guix as package manager and also GNU Shepherd as service/daemon manager.
[1] http://www.gnu.org/software/guix/.
2018-01-31T21:19:27+0100 Carsten Agger wrote:
I was thinking that this warning might in fact apply to my own practices. I don't really work in JavaScript, but I'm using a lot of Python packages in my day-to-day, and I almost never install them from Debian packages.
Why not?
- Versions. Often the packaged versions of Django, Plone, and a lot of
others, are outdated. People normally don't install these things from Debian packages. Plone has its buildout system which pulls stuff from PyPI and other repositories, and for Django applications I always use pip against PyPI for installing.
- Non-root install. When using pip and virtualenv, everything can be
installed locally. This also means you can fix things in the source code without having or using root access.
- Multiple installs - you can have multiple versions of the same
package in non-root environments on the same host - something Django & Plone sites use really a lot.
So there's actually good reasons not to use Python libraries through Debian packages. I imagine the same is the case for JavaScript libraries, not least regarding the necessity of having several different versions coexist in the same OS install.
*On the other hand*, I do realize that if a key dependency suddenly goes missing on PyPI, the applications will break. But I don't think the correct solution for that is to use the Debian package except in very specific circumstances - building an in-house mirror of the dependencies would seem to work better. Or what do you think?
Best Carsten _______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion