Yeah, an overwhelming majority have expressed frustration at this title changing, but they insist on doing it routinely. I understand fixing editorialized titles, but they are not doing that. In most cases, they change it to a far more useless title.
Often the article title will have some implied context, and that is completely lost when it is posted to a general aggregation site like HN. This is just one of many cases where changing the title makes no sense at all.
Maybe mods could post the original title and their change as comment for people to vote on as feedback. That would also mean we would finally know who the mods are...
Can someone explain the situation with eggs and all the installation utilities? After years of programming in python, I still don't understand why everyone makes such a huge deal of installation, which is basically copying things somewhere in the PYTHONPATH.
First, this does not require code to execute (which setuptools require).
Second, the problem is to know what to copy, or rather what to get. even when it's pure python it can be a problem (e.g py2 vs py3) and it's even more of one with e.g C extensions, where you have a choice of building it from source (thus requiring gcc and all build dependencies such as headers) or getting a pre-built binary tied to a given platform.
Ruby gems support that since quite some time, and it's a bliss to install e.g the libv8 gem in a few seconds vs a lengthy build.
Oh, so it's more of an improvement rather than "eggs are horribly broken". I think I'm confused with the "easy_install vs pip" thing, where I also don't see much of a difference.
I've long thought the better mechanism is to hook into the destination platform's native package system. A la BSDPAN.
[Such that installing your language-specific package causes appropriate entries to appear in the system's global database of installed packages. Thus making it easier to identify candidates for upgrade, ensure dependencies are correct, remove redundant libs and so forth]
I'd love to see support for writing directly into distribution's package managers' databases added to things like pip, npm, gems, etc. too but I'm curious what playing nicely with automake gains here. I'm not too experienced with it, and I don't quite see where it would fit into that process.
I think of automake as being more part of the build process. But if things worked as you and inopinatus suggest, and you have taught something like pip 2.0 to bypass the rpm package manager and instead add records directly to the RPM database for a binary wheel package that pip has installed, aren't you kind of routing around any problems of a distribution's compatibility with a language's custom build process entirely?
Or did you mean to reply one level up? Though, again, I'm not sure where automake would help with converting one binary package format into a distribution-specific binary format.
Automake is most definitely a build tool, and I believe that should be orthogonal to the package manager (even though we're seeing convergence in this area with things like go, virtualenv, npm and so on).
The thing with automake is:
1. Distros know how to package it. With cdbs, a debian/rules file for a properly autotooled package is only a couple of lines.
2. Because everything boils down to shell and makefile fragments, you can extend it to fit your corner cases fairly easily.
I believe most of the point is not in installing such packages into system libraries. The point is easy and fast installation into a virtualenv, avoiding the whole recompilation of exctensions phase.
So here's my question: Are things in a wheel allowed to rely on ANY site-packages? IF not, this is spectacular. If so, another unfortunate attempt in the long long struggle.
I'm not sure if this answers your question, but the format includes PKG-INFO, which includes a "Requires" field. How do you envision disallowing dependencies for python packages working? Would all packages have to contain all of their dependencies? I don't think that would ever happen in python-land. It would break lots of things, for dubious benefit.
PKG-INFO has included "Requires" since PEP 314, and I think actually there was tool support for it before that. So it might be a gradual process, but we're getting there. In the meantime, if you can, use a modern tool like "pip". If you can't because you're on Windows, it seems like this new "wheel" format is intended to ease construction of "bdist_wininst" or "bdist_msi" distributions from "sdist" distributions, so that should make your life better too.
Only if you want to limit the people who can install your software to those with one of the package managers and configurations you target, and who have root.
To give a specific example of what michaelhoffman wrote, I have multiple Python virtual installations because my full regression suite tests for about 12 different installation possibilities, including for nice error reporting if a given module isn't installed.
There's no way to do that using the standard package managers, except by the much more complicated solution of having multiple OS instances available.
Leaving dependency management to distros can cause problems when they upgrade a package to a new one that breaks the old API or when they lack a package for a library you need. Dependency isolation is something that Java got right: compile everything into one jar and then deployment is just copying the jar and executing it.
The drawback is that you are responsible for security vulnerabilities in the libraries you install.
The drawback is that you are responsible for security vulnerabilities in the libraries you install.
That is a much larger problem than most people realize. It makes vulnerable dependencies fairly impossible to deal with.
If an OpenSSL bug comes out, I upgrade OpenSSL on all systems in my enterprise. Everything linked to it is automagically taken care of. If a vulnerable library is buried into jar files (or whatever equivalent in your language of choice), I'm screwed. You'll never find those, and there is no assurance that your systems are patched.
If I put on my developer or end-user hat, I totally agree with you. But for most software, this is dangerous.
Dependency isolation is something that Java got right: compile everything into one jar and then deployment is just copying the jar and executing it.
So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries. (Actually I'm not sure even java thinks jars are the right solution for libraries.) You'd probably get more agreement if it were declared the right way to do AMIs or buildout recipes or whatever.
The drawback is that you are responsible for security vulnerabilities in the libraries you install.
It's one thing to say that the sysadmin is responsible for security, but it's another to make sure they have access to fifty rebuilt binary distributions every time a library upon which those depend has a security update. There's dependency isolation and then there's dependency isolation.
> So that's why jars are always 100 MB! I don't think the python community will ever perceive this as the "right" way to distribute libraries.
I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications. Compiling everything into one simplifies deployment. It does not simplify public distribution.
> the sysadmin is responsible for security [...]
It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application. In Python this is normally stored in the file "requirements" in the root of the source tree. Java projects have similar things, so does Haskell.
I'm not advocating it as the right way to distribute libraries. It's the right way to deploy applications.
OK, I agree that's a different case, one for which jars may be appropriate whenever you don't have access to an OS-level package manager. But when is that? When using Windows, but not in the enterprise? Surely most would avoid that grim situation. Since I use apt or the equivalent to install and update apps (unless I have a reason to be closer to the current version), I primarily think of python distributions as providing libraries, although of course they may include applications as well.
It just means that whoever is responsible for security (which should be operations _and_ development, IMO) need a list of the libraries used as part of an application.
Of course it's nice when the applications one installs are supported by developers in the same organization, but it's a rare luxury that doesn't obtain for the typical sysadmin. Even in that case, however, aren't you proposing to make a lot of work for yourself that your package manager is happy to do instead?
