On 13 January 2015 at 06:02, Steve Dower wrote:
>> On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan wrote:
>>> For the time being, things like PyInstaller, PyRun, Portable Python,
>>> etc are going to offer a better solution than anything we provide in
>>> the standard installers.
>>
>> See also Ana
Martin v. Löwis wrote:
> Am 04.01.15 00:34, schrieb Steve Dower:
>> so I'm keen to hear whatever feedback people have.
>
> One issue that I always wanted to address is patch releases. There are two
> aspects I dislike about the current implementation
>
> a) an upgrade install first uninstalls the
Am 04.01.15 00:34, schrieb Steve Dower:
> so I'm keen to hear whatever feedback people have.
One issue that I always wanted to address is patch releases. There are
two aspects I dislike about the current implementation
a) an upgrade install first uninstalls the previous installation
(removing al
> On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan wrote:
>> For the time being, things like PyInstaller, PyRun, Portable Python,
>> etc are going to offer a better solution than anything we provide in
>> the standard installers.
>
> See also Anaconda and Enthought Canopy. I think miniconda, for ins
On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan wrote:
> For the time being, things like PyInstaller, PyRun, Portable Python,
> etc are going to offer a better solution than anything we provide in
> the standard installers.
>
See also Anaconda and Enthought Canopy. I think miniconda, for instance,
On Mon, 12 Jan 2015 17:26:43 +, Steve Dower
wrote:
> David Anthoff wrote:
> > Yes, those are good examples. Right now doing this in the way these guys do
> > is
> > too much work for our small project... Anything that makes this easier
> > would be
> > appreciated.
>
> I don't see how. All
David Anthoff wrote:
>> I'll look into this, but it probably isn't going to work as part of
>> the installer. I have previously looked into being able to install arbitrary
>> side-by-side copies of Python, but that's near impossible as well.
>> Windows Installer doesn't really let you just copy fil
On 10 January 2015 at 11:29, Ethan Furman wrote:
> On 01/09/2015 05:01 PM, David Anthoff wrote:
>> On 01/09/2015 04:09 PM, Steve Dower wrote:
>
>>> The only reason I hesitate on this is that it could cause significant
>>> confusion for someone who doesn't really understand the implications,
>>> wh
On 01/09/2015 05:01 PM, David Anthoff wrote:
> On 01/09/2015 04:09 PM, Steve Dower wrote:
>> The only reason I hesitate on this is that it could cause significant
>> confusion for someone who doesn't really understand the implications,
>> while people like yourself who have thought about this are
> I'll look into this, but it probably isn't going to work as part of the
installer. I
> have previously looked into being able to install arbitrary side-by-side
copies
> of Python, but that's near impossible as well. Windows Installer doesn't
really
> let you just copy files - it isn't part of its
David Anthoff wrote:
> It would be great if the new installer supported silent, portable installs.
> What I have in mind is a silent installation that drops all the necessary
> files
> for a working python into a folder, but does not put ANY file anywhere else
> and
> does not register anything a
On 1/9/2015 12:34 PM, David Anthoff wrote:
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
> 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.
It w
On 7 January 2015 at 00:12, Antoine Pitrou wrote:
> On Tue, 6 Jan 2015 23:56:30 +1000
> Nick Coghlan wrote:
>> "pip" is problematic on Linux as well (due to the pip/pip3 split at
>> the system level). Hence this section in the stdlib docs:
>> https://docs.python.org/3/installing/#work-with-multip
On Tue, 6 Jan 2015 23:56:30 +1000
Nick Coghlan wrote:
> On 5 January 2015 at 18:17, Paul Moore wrote:
> > On 5 January 2015 at 01:20, Steve Dower wrote:
> >> 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
On 6 January 2015 at 13:56, Nick Coghlan wrote:
>> If we can't get PATH sorted out, we need to do something about this,
>> IMO. I don't know what (believe me, I tried to find a solution)
>> unfortunately.
>
> I personally believe we should aim to make the "Windows" section in
> the above link univ
On 5 January 2015 at 18:17, Paul Moore wrote:
> On 5 January 2015 at 01:20, Steve Dower wrote:
>> 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 l
On 5 January 2015 at 21:47, Steve Dower wrote:
> Paul Moore wrote:
>> tl;dr We should have "Add this Python to PATH" as a user choice on the
>> initial
>> installer screen, applicable to whichever install type the user chooses.
>> Details
>> as to why are below.
>
> I agree. I'll work this up be
Paul Moore wrote:
> tl;dr We should have "Add this Python to PATH" as a user choice on the initial
> installer screen, applicable to whichever install type the user chooses.
> Details
> as to why are below.
I agree. I'll work this up before alpha 1. (FWIW, it defaults to unselected.)
Displaying
tl;dr We should have "Add this Python to PATH" as a user choice on the
initial installer screen, applicable to whichever install type the
user chooses. Details as to why are below.
On 5 January 2015 at 17:09, Steve Dower wrote:
> Paul Moore wrote:
>> Steve is in essence saying that it's not possi
On 05/01/2015 17:09, Steve Dower wrote:
Paul Moore wrote:
Steve is in essence saying that it's not possible to sanely manage PATH as part
of the new installer, but that py.exe makes that unnecessary.
It's actually not possible to sanely manage PATH from any installer - it really needs to
be h
Ethan Furman:
> On 01/04/2015 02:56 PM, Steve Dower wrote:
>
>> 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
>>> insta
Mark Lawrence wrote:
> If I'm reading this correctly it means that py.exe gets picked up from PATH so
> it could be 32 or 64 bit. Does this mean that the launcher could be or needs
> enhancing so 32 or 64 bit can be selected? I'm not sure if anything can be
> done
> about pyw.exe, perhaps you (pl
On 01/04/2015 02:56 PM, Steve Dower wrote:
> 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
On 5 January 2015 at 08:40, Donald Stufft wrote:
>> The biggest problem here is that py.exe doesn't help in the slightest
>> with script wrappers like pip.exe, virtualenv.exe, py.test.exe,
>> ipython.exe ... I've actually drifted away from using py.exe because
>> of this. Having just the interpret
On 04/01/2015 22:56, Steve Dower wrote:
Paul Moore wrote:
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 II
> On Jan 5, 2015, at 3:13 AM, Paul Moore wrote:
>
>> py.exe is more important than ever. It's still installed into the Windows
>> directory for all-user installs, and into the Python directory for
>> just-for-me. It's installed in a way that will make upgrades more reliable
>> (so if you inst
On 5 January 2015 at 01:20, Steve Dower wrote:
> 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
On 4 January 2015 at 22:56, Steve Dower wrote:
>> 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?
>
> Yes, and in general the later installed version will win and system-wide
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 expli
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 re
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
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
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 th
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 J
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
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-installe
General comments:
I was a bit concerned when Steve first posted his plans for the Windows
installer and making a web installer forcing re-downloads for every
install, and expressed those privately. I'm no longer concerned, this
outlined scheme is good, but I have some suggestions to make it gr
On Sun, Jan 4, 2015 at 10:34 AM, Steve Dower wrote:
> http://stevedower.id.au/blog/the-python-3-5-installer/
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 globall
On Sat, 3 Jan 2015 23:34:05 +
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-
> On Jan 3, 2015, at 6:34 PM, 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-i
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 cha
42 matches
Mail list logo
