Re: [Python-Dev] New Windows installer for Python 3.5

2015-01-12 Thread Steve Dower
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 files - it isn't
>> part of its intended functionality. It isn't too difficult to build custom
>> MSIs with certain parts of Python (such as the DLLs and the standard
>> library, but no docs, headers or EXEs) in a way that won't conflict with
>> other installs, but you're still using an MSI here which is not
>> necessarily ideal.
> 
> Are administrative MSI installs an option, though? They don't register 
> anything
> but just drop files, right? But see my comments below about a zip drop, which
> would be a much, much nicer option in my opinion.

Not to my knowledge. An administrative install puts the files in a shared 
location and allows users to run much faster installs that will then refer to 
that shared location rather than copying the files locally. As I said, MSI 
doesn't support plain file drops (often called "xcopy install" - you use that 
term later, but I'm not sure how well known it is).

>> We could release a ZIP file containing all the Python files.
> 
> That would be absolutely FANTASTIC and would solve all problems around this
> topic. In theory we could handle this ourselves on our end, but this is for a
> small open source project and we are really hesitant to take on another 
> software
> packaging job. Doing this right just for our product would be a fair amount of
> work, we would have to do this with every new Python release, we might mix
> things up etc., and really we are more interested in our piece of software 
> than
> packaging Python ;) I think it would be a much nicer model if there was a zip 
> to
> download from python.org.

Apart from the bit below, this would be identical to you installing Python once 
on your own machine and zipping up the files yourself. For the (considerably) 
less than 1% of Python users who want to do this, I don't think it's a big ask.

> There is another issue that keeps us from hosting our
> own files: we would have to figure out licensing issues, both related to 
> python
> and to the msvcr*.dll and msvcp*.dll. I would feel much more comfortable if we
> didn't distribute python or other binaries, but just downloaded stuff from
> python.org as part of the setup process.

IANAL, but I've dealt with enough licensing issues in my day job that this 
makes me even more concerned about making a ZIP file available. If you're 
planning to do this, putting up a ZIP file could potentially expose Python (and 
presumably the PSF indirectly) to the liability that you should be taking on as 
a redistributor, if it's that important to your product. Without an actual 
legal opinion, I'm now -1 on making a ZIP download available for this purpose.

>> 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 also capable
>> of finding workarounds and don't really need the ZIP file apart from
>> convenience.
> 
> I was not clear in my previous email. I have NOT found a way to work around
> this. I have tried various hacks, but none really works. I got pretty far, but
> none really worked in all cases in a robust way. So I would certainly welcome 
> a
> downloadable zip file a great deal. Is there maybe a compromise for now to 
> have
> such a zip on the server, but not advertise it widely, and maybe put an
> "experimental"/"beta" moniker into the filename?

I gave you a workaround. Install Python just for yourself and zip up the 
install directory.

> I assume you would include the MS VC runtime files msvcr100.dll and 
> msvcp100.dll
> in such a zip file?

Either that or redistribute them using the tools provided by Microsoft (there 
are redistributable merge modules and executable installers available). The 
advantage of the latter approach is that your users will automatically get the 
latest versions and security fixes.

> Is there any chance this might even be done (as an experimental version) for
> Python 3.4?

You'd have to ask Martin, so probably not. But the workaround I gave you will 
work for 3.4.

>> Making some of the fixes to
>> make python.exe more portable would relieve my concerns here.
> 
> I see that. For our cases things seem to work, but I agree, it would be good 
> if
> python.exe would try hard to work in a xcopy mode.
> 
>>> The old MSI installer sort of had something like that with the MSI
>>> administrative install option. But it never really worked because
>>> the administrative install didn't drop the MSVC runtime dlls
>>> anywhere, as far as I could tell. At some point I hacked around that
>>> by modifying the MSI file in my setup program to also drop the MSVC
>>> runtime dlls, but
>>> that was VERY hack

Re: [Python-Dev] New Windows installer for Python 3.5

2015-01-12 Thread R. David Murray
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 they've done is literally copy a Python
> installation into their install directory. Yes, they have their own
> launcher executables (py2exe generated, it looks like) and have
> precompiled the standard library and put it in a ZIP file, but you
> don't even need to go that far. Without knowing anything about your
> project I can't give specific suggestions, but simply dropping a
> Python installation in is not that difficult (and until the issues
> that Nick referred to are fixed, will have the same problems as
> TortoiseHg presumably has).

That's what py2exe *does*.  It does all the python-integration and
launcher-building work for you.  I use it for a small project myself
(proprietary), which I build an installer for using Inno Setup.  Works
very well, supports python3.

--David
___
Python-Dev mailing list
Python-Dev@python.org
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

2015-01-12 Thread Chris Barker
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,
may give you just what you need, if you don't want to go the
py2exe/PyInstaller approach (though you probably do want to go that way, as
far as I can tell from your description of your use-case.

I'm inclined to think that this does not belong as part of the standard
installer.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
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

2015-01-12 Thread Steve Dower
> 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, may
> give you just what you need, if you don't want to go the py2exe/PyInstaller
> approach (though you probably do want to go that way, as far as I can tell 
> from
> your description of your use-case.

Actually, both Anaconda and Canopy suffer from the initialization process 
issues. You can't really use virtualenv with either of them unless they set the 
registry PythonPath value (since they won't find the libraries they need to 
launch), and if you install both then they'll fight over the registry key and 
you'll get Canopy launching with Anaconda's path or vice-versa.

> I'm inclined to think that this does not belong as part of the standard
> installer.

The problems are inherent to the standard python.exe, and are likely part of 
the standard pythonXY.dll. Nick's scared of fixing it, so I'm absolutely 
petrified :)

Cheers,
Steve

> -Chris
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com