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
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
