Re: [Python-Dev] New Windows installer for Python 3.5
On 3 January 2015 at 23:34, Steve Dower wrote: > I've put together a short post showing where I've been taking the Windows > installer for Python 3.5, since I know there are interested people on this > list who will have valuable feedback. > > http://stevedower.id.au/blog/the-python-3-5-installer/ > > Nothing is merged in yet and everything can still change, so I'm keen to hear > whatever feedback people have. I've tried to make improvements fairly for > first-time users through to sysadmins, but if I've missed something big I'd > like to hear about it before we get too close to alpha 1. Overall, this looks good. One question - will it be possible to install both 32-bit and 64-bit Python on the same machine? Currently, you need a custom install to do this (as the default directory doesn't include the architecture) and IIRC there's some oddness around install order. It would be nice if installing both versions were a supported option, both for the "default" install and in custom installs. Also, what happens now with setting PATH? Is Python (and the scripts directory) added to PATH by default? If so, what happens when you install 2 versions of Python? In case it's not clear, I'm thinking of the impact on build machines, which often have multiple versions, in both 32- and 64-bit forms, installed simultaneously (but can also be used as a "normal" development machine, and for that purpose will want a selected Python version as the default one. Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default? (Sorry, that was more than one question :-)) Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 4 January 2015 at 22:01, Paul Moore wrote: > On 3 January 2015 at 23:34, Steve Dower wrote: > Also, how does the launcher py.exe fit into the picture? Is it still > installed into the Windows directory? What about for a user install? > Are Python scripts associated with the launcher, and if so, how does > it pick up the version you selected as default? > > (Sorry, that was more than one question :-)) The proposed installer changes look like a great improvement to me, but I think Paul's questions suggest that it will be useful to capture the many decisions involved in the redesign as a PEP. That serves a couple of useful purposes: 1. It helps guide the design itself, and ensure that the various usage scenarios (like build machines) are suitably covered. 2. When Python 3.5 is released, we can point readers of the What's New document to the PEP as a reference for the detailed decision making process that went into the changes that were made. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
I believe that the new default location addresses your first question: the 64-bit will install in c:/Program Files/Pythonxx and the 32-bit in c:/Program Files (x86)/Pythonxx (at least this has been my standard practice for several years). Eric On Jan 4, 2015 7:03 AM, "Paul Moore" wrote: > On 3 January 2015 at 23:34, Steve Dower wrote: > > I've put together a short post showing where I've been taking the > Windows installer for Python 3.5, since I know there are interested people > on this list who will have valuable feedback. > > > > http://stevedower.id.au/blog/the-python-3-5-installer/ > > > > Nothing is merged in yet and everything can still change, so I'm keen to > hear whatever feedback people have. I've tried to make improvements fairly > for first-time users through to sysadmins, but if I've missed something big > I'd like to hear about it before we get too close to alpha 1. > > Overall, this looks good. One question - will it be possible to > install both 32-bit and 64-bit Python on the same machine? Currently, > you need a custom install to do this (as the default directory doesn't > include the architecture) and IIRC there's some oddness around install > order. It would be nice if installing both versions were a supported > option, both for the "default" install and in custom installs. > > Also, what happens now with setting PATH? Is Python (and the scripts > directory) added to PATH by default? If so, what happens when you > install 2 versions of Python? > > In case it's not clear, I'm thinking of the impact on build machines, > which often have multiple versions, in both 32- and 64-bit forms, > installed simultaneously (but can also be used as a "normal" > development machine, and for that purpose will want a selected Python > version as the default one. > > Also, how does the launcher py.exe fit into the picture? Is it still > installed into the Windows directory? What about for a user install? > Are Python scripts associated with the launcher, and if so, how does > it pick up the version you selected as default? > > (Sorry, that was more than one question :-)) > > Paul > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ericfahlgren%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
Thanks for all the comments. I've responded all at once, since I don't think
any of the points raised are going to immediately turn into intense discussion.
Feel free to trim the rest of the post if you want to respond to just one of
the points.
Donald Stufft wrote:
> Does signing the .exe’s that ship with Python effect pip at all? I’m guessing
> not since pip.exe is actually a generic .exe that we use for any project and
> is
> shipped inside of the .whl files but I figured i’d ask.
>
> Depending on the answer above, does it make sense to sign the generic .exe
> (does
> that even work if we rename it?) which will get used for anything that uses
> entry points on Windows?
Actually, I don't think the generic .exe can be signed, since embedding the
script within the file will invalidate the certificate. It's better not to have
the certificate at all in this case. If we were still using the separate
pip-script.py file then we could sign it.
> Is there any plan to backport this to 2.7 (presumably after some experience is
> had with it in 3.5)?
No. I'm very much in the "2.7 is finished" camp. Hitting rebuild every now and
then for security updates is the extent of my interest (and in large part
that's because if nobody is producing builds then I'll probably end up having
to produce the builds to run on Azure anyway).
Antione Pitrou wrote:
> One comment: I would find it a bit confusing if the default install path
> changes when using the customized install. OTOH, maybe you can't choose
> another default there.
It's a tough one to choose, honestly. I really don't want separate "customize"
buttons for per-user and all-user installs (too many up front decisions,
especially for people who really should just choose the first option). My
reasoning for having "C:\Python35" as the default there is to simplify the
"just give me the old style install" case, but that may turn out to be a bad
reason. I'm not sure yet.
ChrisA wrote:
> You talk of installing by default into Program Files, and having a
> separate per-user installation mode. How do these two installation
> targets interact? Suppose someone installs 3.5 globally, then installs
> 3.6 for self only? Or installs 3.5.1 for self only? I would normally
> expect a per-user installation to trump a global one, but this could
> make for a lovely dep-hell on a system that's used by one person, who
> then isn't sure what was installed as admin and what wasn't.
Yeah, it gets a little messy, especially if you keep adding all the Python
versions to PATH (Windows will always put per-user PATH entries at the end).
The py.exe launcher handles this best, and the system version will always be
found first.
As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs
"py -3.6") and 3.5.0 vs 3.5.1 can only be installed at the same time if one is
system-wide and the other is per-user. In this case, the per-user one will be
used by py.exe, even if it is older than the system-wide one.
Compared to the current situation, the per-user and all-user installs do not
interfere as much.
> (Also: I'm assuming that pip would require admin privs if Python is in
> Program Files, and won't require admins if it's per-user, right? Same
> as the Python installer itself?)
Correct. The pip guys are already looking into handling installs in this case
since it matters on *nix, and having read-only Python installs on Windows will
only make it more similar. It seems likely in this case that the user
site-packages folder will be used if your user can't write to the shared
site-packages. If you can write to it (either per-user install or running pip
as admin) then you'll install to that folder.
I am fully expecting to find the most issues in this area once we change the
install location, and I don't think we can fix all these issues without
actually releasing the change. So it's a bit of a risk, but one I feel is worth
it. Of course, if the community and release manager disagree, I'll happily back
it out and we can focus on testing it directly for a bit before inflicting it
on our users.
Glenn Linderman wrote:
> But here's another idea: automatically keep all the .msi and .cab files used
> for
> the first installation of Python with it in the directory from which it runs
> (naming convention... prefix them all with python-3.5.0a1..(msi|cab) It
> is very likely that a reinstall will use the same components (if more are
> needed
> on a later install, add them to the directory also). And a good naming
> convention makes it obvious what to delete when done with the installer.
Unfortunately, I'm fairly restricted on naming convention. For some reason
Windows Installer requires CAB files to be 8.3 names, where some of the 8 are
reserved, so the names are pretty meaningless.
However, Windows does automatically cache all the files (typically in
C:\ProgramData\Package Cache) so that repairs and uninstalls don't need to
redownload anything, and
Re: [Python-Dev] New Windows installer for Python 3.5
On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower wrote:
> (Windows will always put per-user PATH entries at the end). The py.exe
> launcher handles this best, and the system version will always be found first.
>
> As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs
> "py -3.6") and 3.5.0 vs 3.5.1 can only be installed at the same time if one
> is system-wide and the other is per-user. In this case, the per-user one will
> be used by py.exe, even if it is older than the system-wide one.
>
Wait, what?
If I'm reading this correctly, PATH is set such that an all-users
version trumps a self-only version, but when you use the py.exe
launcher, it's the other way around? That seems extremely confusing.
But if that's not a deliberate design decision and isn't enforced by
external code, would it be possible to simply invert that for PATH,
and have a per-user installation always be found ahead of a
system-wide one? That would make reasonable sense, if it can be done.
> Incidentally, whoever came up with the py.exe launcher deserves a medal. It's
> made dealing with multiple versions amazingly easy.
https://www.python.org/dev/peps/pep-0397/ - and I agree :)
ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On 1/4/2015 2:56 PM, Steve Dower wrote: Unfortunately, I'm fairly restricted on naming convention. For some reason Windows Installer requires CAB files to be 8.3 names, where some of the 8 are reserved, so the names are pretty meaningless. Least common denominator, I'm sure. But a pretty stupid limitation at this point in time. It would convince me to use a different installer technology, along with the many obscure and arcane features of .msi and .cab files that already convinced me of that years ago. So then I'd suggest storing all the files in a directory named "python-3.5.0a1-install-files" unless that would also have to be limited to 8.3 :( However, Windows does automatically cache all the files (typically in C:\ProgramData\Package Cache) so that repairs and uninstalls don't need to redownload anything, and this cache is automatically managed to preserve disk space. If you add new features later then you won't have the files in the cache, which is about the only way that this doesn't already fit your suggestion. I think it's fairly unlikely that people will be surprised by this, though when the first complaints come it about it I'll happily reconsider. Handy, I was unaware of this, being turned off long ago by the stupid features of .cab and .msi, so the good features have escaped me. If there is a way to convince it to download the rest of the files based on the checkbox, that would be handier. Checkbox could be worded "download install components even for features not installed" which should keep people from checking it unnecessarily. You mentioned a help link... couldn't the help text be included (text compresses great!) and popped up in a window? >And a related idea: for custom installs, record the choices made in a metadata >file in that same directory, and after the first install, subsequent installs >could have a 3rd single-click install: same custom install as last time. This >would be kept in the directory with the installer, so could be applied to a >zillion machines, and an install option /ditto would allow those choices from >the command line. That way, the administrator could use the friendly interface >to install the first machine, making the appropriate choices, and then just run >"python-3.5.0a1.exe /ditto" on all the other zillion-1 machines, without needing >to learn any other obscure command line parameters. I don't care how you spell >/ditto, as long as there is documentation. This is really interesting, and certainly possible. I'll keep it in mind as something to look into after alpha. (What may be easier is a message at the end showing the command line to use that will perform the same installation silently... hmm...) If you can display the command line (which would be interesting), then you can save it in a file, and invoke it from the 3rd single-click install button! Or if you can't, at least make sure the command can be copied to the clipboard, and the administrator could paste it to python-3.4.0a3.ditto.cmd :) Incidentally, whoever came up with the py.exe launcher deserves a medal. It's made dealing with multiple versions amazingly easy. Totally agree! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
On Mon, Jan 5, 2015 at 12:20 PM, Steve Dower wrote: > Unfortunately, Windows enforces the PATH ordering. It constructs the PATH > from two registry keys, one is the system-wide value (that requires > administrative privileges to modify) and it is followed by the user's value > (that does not require administrative privileges). This is probably for > security reasons and can't be changed. > > PATH also suffers from including the most-recently installed Python version > first, rather than the most recent version. Basically, py.exe gives the > behaviour we want and PATH simply can't do it. > > I think this means the best way to make multiple versions work properly is to > rename python.exe to python3.5.exe, then install the launcher as python.exe > and python3.exe (with some logic to look at its own name) so it can resolve > the right version. Maybe we can even extend the launcher to resolve launchers > in Scripts (pip.exe, etc.) and have consistent rules there too? > > Or perhaps this is more trouble than it's worth, and we should let "py.exe" > have a fixed set of rules and let PATH work as people have come to expect. > Thoughts? Great. :( Well, if there's no changing the PATH behaviour, so be it... the question is, should py.exe match that, or do the sane thing? Neither option is ideal. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Windows installer for Python 3.5
Chris Angelico wrote:
> On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower wrote:
>> (Windows will always put per-user PATH entries at the end). The py.exe
>> launcher handles this best, and the system version will always be found
>> first.
>>
>> As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs
>> "py -3.6") and 3.5.0 vs 3.5.1 can only be installed at the same time if one
>> is
>> system-wide and the other is per-user. In this case, the per-user one will be
>> used by py.exe, even if it is older than the system-wide one.
>>
>
> Wait, what?
>
> If I'm reading this correctly, PATH is set such that an all-users
> version trumps a self-only version, but when you use the py.exe
> launcher, it's the other way around? That seems extremely confusing.
> But if that's not a deliberate design decision and isn't enforced by
> external code, would it be possible to simply invert that for PATH,
> and have a per-user installation always be found ahead of a
> system-wide one? That would make reasonable sense, if it can be done.
Unfortunately, Windows enforces the PATH ordering. It constructs the PATH from
two registry keys, one is the system-wide value (that requires administrative
privileges to modify) and it is followed by the user's value (that does not
require administrative privileges). This is probably for security reasons and
can't be changed.
PATH also suffers from including the most-recently installed Python version
first, rather than the most recent version. Basically, py.exe gives the
behaviour we want and PATH simply can't do it.
I think this means the best way to make multiple versions work properly is to
rename python.exe to python3.5.exe, then install the launcher as python.exe and
python3.exe (with some logic to look at its own name) so it can resolve the
right version. Maybe we can even extend the launcher to resolve launchers in
Scripts (pip.exe, etc.) and have consistent rules there too?
Or perhaps this is more trouble than it's worth, and we should let "py.exe"
have a fixed set of rules and let PATH work as people have come to expect.
Thoughts?
Cheers,
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
