On 28 March 2014 21:06, Nick Coghlan firstname.lastname@example.org wrote:
So consider me in the school that suggests this be a standard installer feature that can be applied to any entry point script, rather than something that varies by project.
Doing that also implies (detecting and) deliberately ignoring any versioned entry points created by setup.py. I'd suggest going for a rule that if a project defines two entry points with the same definitions, where one ends in the pattern -?\d(.\d)? (in other words, -X, -X.Y, X or X.Y) but they are otherwise the same, then ignore the versioned one. If we don't do this, we'll likely end up with abominations like virtualenv-2.7-3.4.exe.
I'm not 100% sure whether you're saying that the installer should mandate a versioning policy, or if the user can specify. The altinstall case suggests we need a user override option.
There's also the question of if I do "pip install virtualenv --use-versioned X,X.Y" and then "pip install -U virtualenv" will the installer remember my versioning choices for the upgrade? Doing so needs some complex logic. Not doing so means that "pip install -U pip" could change the executables ensurepip had chosen to create.