Mark Mikofski added the comment:
I've set up AppVeyor CI (http://www.appveyor.com/) to build the latest tag in
the 2.7 branch of cpython at https://hg.python.org/ and to deploy zip files of
x86 and x64 standalone builds to
http://breakingbytes.alwaysdata.net/PythonBootstrap/. The builds use a
Changes by Larry Hastings la...@hastings.org:
--
nosy: -larry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
___
___
Python-bugs-list
R. David Murray added the comment:
I just reviewed this whole issue. Steve says that the original issue you
raised will be resolved in 3.5 (I believe pretty much already has been?). So
given the last couple of messages I'm going to re-close this, as a continuing
discussion here seems to be
Changes by Mark Lawrence breamore...@yahoo.co.uk:
--
components: +Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
___
___
Mark Mikofski added the comment:
J. Morton and anyone else needing a Python-2.7.9 Windows release to use without
admin rights or to embed in a personal application can see my blog to roll
there own or download one of the versions from my dropbox
J. Morton added the comment:
As the originator, I've noticed that the discussion (while illuminating - and a
lot more than I expected!) seems to have gone off on several tangents. I'd
like to remind everyone that this request is for an unrestricted Windows
install (e.g. binary) package of
Nick Coghlan added the comment:
I think we learned our lesson re making decisions at the language summit
(rather than focusing on bringing folks up to speed on a problem area) after
needing to later reverse engineer the rationale for some of the decisions made
at the first couple :)
Paul Moore added the comment:
That sounds reasonable. I understand the need for face-to-face discussion on
something like this, although I do think there's been something of a tendency
in the past for things decided at PyCon to receive a certain amount of
resistance from people who weren't
Paul Moore added the comment:
Regarding the poor relation argument, I'd see that as the other way round. We
don't have the resources to deal with major breakages, so we should be
relatively cautious.
--
___
Python tracker rep...@bugs.python.org
Mark Lawrence added the comment:
I'm concerned about being overcautious so that nothing ever happens. Do
something, break it, fix it. If you delay all you do is put off the fix. Plus
I've every confidence in our Windows developers to just do the right thing.
--
Steve Dower added the comment:
Paul has basically summed up the pragmatism beats purity side of the argument.
Whether we like it or not, users are mostly coming to python.org for their
installer, and we need to support that.
That said, we can do some things to support all three cases once we
Mark Lawrence added the comment:
python35.exe follows things like pip so +1. py.exe to python.exe -1 from me,
how about pylaunch.exe as it's explicit? As for urgency in the Python world
Windows is and always has been the poor relation compared to *nix, so I say
let's bite the bullet and get
Paul Moore added the comment:
Personally, I'd like to have 3.5 be the release that changes to using Program
Files as the default install, and offers a per-user install to Appdata. I
suspect there will be enough fallout from that change to keep us busy. Let's
look to 3.6 for major renamings of
Paul Moore added the comment:
One implication of Nick's (and Steve's) position seems to me that we don't view
per-user installs as a key aspect of the python.org installers. And yet the
impression I get of the direction that the 3.5 installers is taking seems to
contradict that - there's a
Nick Coghlan added the comment:
From a general philosophical perspective, I share Steve's view - the vast
majority of potential CPython users don't want to be consuming upstream Python
themselves, they want to be getting it from a redistributor.
This has nothing to do with the quality of the
Nick Coghlan added the comment:
Short version of the above: I personally think we should be focusing on
addressing the system Python and Python as a library cases upstream, as
we're the only ones that can do that.
Solving the latter problem well then also sets the baseline for user focused
Steve Dower added the comment:
Sorry, Standard Operating Environment. I intended it as shorthand for the as
if it were shipped with the OS case.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
Nick Coghlan added the comment:
I agree the migration to Program Files a different installer build process is
more than ambitious enough for 3.5.
For the embedding case, it's not that it *can't* be done, it's just a PITA.
Perhaps for the per-user no-admin-rights needed case, we could direct
Nick Coghlan added the comment:
Along those lines, another option to consider would be offering to publish
Portable Python from the python.org release pages in addition to publishing the
less comprehensive CPython-only installers.
--
___
Python
Nick Coghlan added the comment:
Larry,
Bringing you into this discussion as CPython 3.5 release manager - we're trying
to figure out what role we'd like the CPython Windows installers to play in the
Windows distribution ecosystem, and I raised the question of whether or not
typical Windows
Ned Deily added the comment:
Bringing an umbrella distribution into the CPython release process seems to me
like a very big leap and would that requires very careful consideration. It
would introduce a whole load of other dependencies into our release process,
i.e. that the third-party
Mark Mikofski added the comment:
WinPython and miniconda are more current distros than portable python, and they
come in both 32 64bit flavors.
Portable python hasn't been updated recently and only offers 32 bit which is
IMO worthless except for the bundle as app case, eg meld installer.
I
Paul Moore added the comment:
Sorry, SOE?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
___
___
Python-bugs-list mailing list
Steve Dower added the comment:
(when does Windows switch to 3.6? Honestly, it can probably never happen...).
On re-read, this isn't quite clear:
Hypothetically, if Windows 10 included Python 3.5, when would it be upgraded to
Python 3.6? Probably never. Back-compat is problematic on Linux,
Steve Dower added the comment:
Yeah, some of those are fairly ambitious, but at the same time, for the SOE use
case we probably don't want the Program Files install at all - it would be a
mix between System32 and CommonFiles, with the same environment issues you'd
see on Linux. Program Files
Steve Dower added the comment:
Also, I do have this topic on the language summit agenda, so I don't really
want to lock anything down before then anyway, but this discussion has been
good to flesh out some of the background and possibilities in advance of that.
--
Paul Moore added the comment:
I agree with Ned, this sounds like a significant change. In particular,
Portable Python seems to currently only offer 3.2.5 at the moment. And it's not
at all clear to me whether it's a 32-bit or a 64-bit version (but I suspect the
former). One thing I'd want to
Steve Dower added the comment:
miniconda does not install all of the sci-data packages, only conda and
python 2.7
miniconda is actually a tool that gives you the conda command, which can be
used to install Python 2.6, 2.7, 3.3 or 3.4, 32 or 64-bit and a huge range of
compatible packages.
Ned Deily added the comment:
This issue seems to be expanding widely in scope and it is not at all clear to
me what actionable items would come out of it. It started as a very
Window-specific problem and now seems to somehow be being extended to the whole
Python ecosphere. What about the OS
Steve Dower added the comment:
Yeah, this is starting to get out of hand. I'm quite happy to leave things sit
until the language summit, when we should have a broad enough representation to
make a start. After that it'll get to python-dev before anything major is
decided, but the
Nick Coghlan added the comment:
As of last month, Microsoft do provide official Python support, but only in the
context of the online Azure Machine Learning Environment:
Nick Coghlan added the comment:
Given the expansion of the discussion to more general questions of getting
CPython from upstream into the hands of end users, I've added in some more of
the distro level folks to the nosy list (Matthias, Barry, Slavek, Robert).
This idea of more actively
Mark Lawrence added the comment:
No this is not a good forum for this discussion. Python-dev or ideas please,
to be followed up by a PEP I'd guess.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
Nick Coghlan added the comment:
Right, I mostly borrowed the issue as a public channel that could reach folks
already invested in the problem space, without needing to tidy things up
sufficiently to make them coherent for a more general audience on python-dev or
python-ideas.
As Steve says,
J. Morton added the comment:
First, thanks for the comments - perhaps there's hope.
But from the viewpoint of a typical user (who does not care about what goes on
in the background), some of what has been said does not match the realities of
development in a corporate environment.
1 –
Mark Mikofski added the comment:
1. J morton: just install Anacondahttp://continuum.io/downloads
2. I will take a look at the msi and see if I can accommodate both installs in
the same installer
--
___
Python tracker rep...@bugs.python.org
Steve Dower added the comment:
@Mark: You can't - MSIs have a single flag indicating whether they should
elevate or not. That's why I moved the 3.5 installer to a new format.
Unfortunately, since we're in a transitional state, admin privileges are
necessary to install the new CRT version, but
Terry J. Reedy added the comment:
99% of Python users should be getting a distribution rather than the
python.org installers.
I do not understand this at all. Why? My understanding is that at least some
of the separate distributions are separate gardens cut off from the wider
Steve Dower added the comment:
My understanding is that at least some of the separate distributions are
separate gardens cut off from the wider pip-accessible python ecosystem.
Maybe some are, but certainly not all of them. There are sometimes
cross-dependencies that require you to go to
Paul Moore added the comment:
99% of Python users should be getting a distribution rather than the
python.org installers
I'm not at all convinced by this logic. On Windows, as far as I'm aware, the
only major Python distributions are Anaconda and Enthought, both of which are
intended
Steve Dower added the comment:
my guess (conceded, this is based on no actual metrics) would be that 99% of
Windows users use the python.org installers, certainly not the other way
around.
Based on numbers I've heard it's certainly a majority currently using the
python.org installers, but
Steve Dower added the comment:
Supporting proper per-user installs of Python 2.7 or 3.4 would require a second
MSI that is configured to not ask for administrative privileges. The code is in
Tools/msi/msi.py if you want to look at it (it's not my code and I have no
intention of touching it),
Mark Mikofski added the comment:
I know this issue is closed, but as there is no voting or plus 1, I'll add my
support for allowing local installation of not just Python-3, but also
Python-2.7. I'm not sure what is gained by adding this restriction, or how
difficult it would be to allow users
Mark Mikofski added the comment:
one more note, NaCl (J. Morton), you can install from the msi to any directory
you want by using the following from a command line opened to the folder where
you have the installer:
C:\path\to\msi\download msiexec /a python-2.7.9.amd64.msi
New submission from J. Morton:
Could not install 3.4.1 on Windows 7 Enterprise SP1 using the .MSI installer,
even when using the ”just for me” option (our IM department has not given us
the necessary rights to run the .MSI installer even in this mode).
Please consider providing 3.4.1 (and all
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
components: +Windows
nosy: +steve.dower, terry.reedy, zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
___
R. David Murray added the comment:
The source tarball is the source tarball. You can built python yourself, but
it does require MSVC. There are issues in this tracker about supporting other
compilers, but for various reasons (mostly having to do with this being a
volunteer community driven
Steve Dower added the comment:
The just for me option isn't really just for me. I'll probably have a real
option in 3.5, though it may still require admin rights.
There's no reason sites like www.portableapps.com couldn't provide true
per-user installers, and Continuum Analytics and Enthought
Changes by R. David Murray rdmur...@bitdance.com:
--
resolution: - later
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22516
___
49 matches
Mail list logo
