Re: [Python-Dev] 3.5 release schedule PEP
On 24 Sep 2014 15:15, "Tim Golden" wrote: > > On 23/09/2014 18:05, Steve Dower wrote: >> >> I'm also considering/experimenting with installing into "Program >> Files" by default, but I suspect that isn't going to work out yet. > > > I'd like to see that go forward: I think it's increasingly difficult to justify Python's position at c:\pythonxx. But it does run the risk of > breaking All The Things. When it was discussed, people spoke about > symlinks (or hardlinks / junctions / whatever) in the appropriate > places to support hardcoded paths, but I don't know how feasible > that will turn out to be. It might be better to offer that as a supported option in 3.5, and then make it the default in 3.6. That will offer a couple of years to work out the issues, rather than a few months. >> I'd like to move the Windows versions onto the next release of VC >> (currently "VC 14" until the branding team figures out what to call >> it). There isn't a promised RTM date for VC 14 yet, so it looks like >> the best available compiler by Beta 1 will be a "Go Live" RC. (The >> "Go Live" marking basically means "we think this is ready for use, >> but expect a round of minor updates/fixes soon - the compiler is >> least likely to be updated, my guess is that it'll be Visual Studio >> UI mostly). > > > My only real misgiving here is that, for a few years, we'll need *three* versions installed to build the active branches: 2008 for 2.7; 2010 for 3.4; and 2014 for 3.5. Am I wrong? 3.4 will go into security fix only mode a few months after 3.5 is released, as happened with 3.3. It does suggest that we shouldn't switch the compiler until: 1. At least a beta of VC 2014 is generally available 2. We're a few weeks out from 3.5 beta 1 (with VC 2014 as an option until then) Cheers, Nick. > > TJG > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%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] 3.5 release schedule PEP
On 24 September 2014 06:13, Tim Golden wrote: > My only real misgiving here is that, for a few years, we'll need *three* > versions installed to build the active branches: 2008 for 2.7; 2010 for 3.4; > and 2014 for 3.5. Am I wrong? Also, will 2014 express edition be able to fully build extensions for Python, 32 and 64 bit? Will it be able to build Python itself? I ask because I'm currently discovering how much fun (basically none) it is to set up the SDK compilers for building extensions, and it would be fantastic if that pain point could be removed. (It's also personally relevant to me now, as my python-dev provided MSDN subscription has run out, so I'm back to only having access to free tools :-)) 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] 3.5 release schedule PEP
On 24.09.2014 03:48, Nick Coghlan wrote: > On 24 September 2014 03:05, Steve Dower wrote: >> Larry Hastings wrote: >>> >>> On 09/19/2014 03:31 PM, Barry Warsaw wrote: >>> I think we need a Python 3.5 Release Schedule PEP. >>> >>> Just checked it in as PEP 478. It should show up here in a few minutes: >>> http://legacy.python.org/dev/peps/pep-0478/ >>> >>> Key facts: >>> . Beta 1 is May 24th 2015, about a month after the end of the PyCon US 2015 >>> sprints. >>> . Final release is September 13, 2015, just over a year from now. >>> >>> Comments? >> >> Martin is no longer producing the Windows installers - that task has been >> handed to me. I'm planning to have a rewritten installer (also in the same >> repo) that should be easier to modify and maintain, as well as being able to >> produce alternative packages (such as a Python 3.5 or stdlib merge module, >> for example), though that doesn't necessarily need to go into the PEP. >> >> I'm also considering/experimenting with installing into "Program Files" by >> default, but I suspect that isn't going to work out yet. >> >> I'd like to move the Windows versions onto the next release of VC (currently >> "VC 14" until the branding team figures out what to call it). There isn't a >> promised RTM date for VC 14 yet, so it looks like the best available >> compiler by Beta 1 will be a "Go Live" RC. (The "Go Live" marking basically >> means "we think this is ready for use, but expect a round of minor >> updates/fixes soon - the compiler is least likely to be updated, my guess is >> that it'll be Visual Studio UI mostly). >> >> I personally don't have any qualms about using the RC compiler for Beta 1, >> and Beta 2 will almost certainly use VC 14 RTM, but I know when I proposed >> this topic that some people were concerned about having the final version >> available for Python 3.5 Beta. >> >> So far I've been building regularly with internal versions of VC and haven't >> been hitting any major issues with Python (OpenSSL has some issues, but I've >> been filing bugs on both sides so they should be worked out soon enough). My >> work is at http://hg.python.org/sandbox/steve.dower (branch: VC14) for >> anyone interested. >> >> For the alphas, I'm contemplating producing two builds (VC 10 and VC 14), >> but I obviously want to settle on one or the other by Beta. Last time we >> discussed it, there was strong support for changing compiler, but I have a >> better idea of the timeline now and it's tighter than I thought... >> >> Thoughts, anyone? > > It's ultimately up to Larry as RM, but I'd personally favour targeting > the newer compiler and runtime, even with the slight risk of > potentially needing to slip our schedule. There's also a fair amount > of wiggle room between the first beta and the first release candidate. I'd rather be conservative here and wait for another Python release before switching VC versions. There are a few important questions that need answers before we can consider a new VC version: * Will there be free versions available ? * Will those free editions include the 64-bit compilers ? * Will those free editions include the optimizing compilers ? * Is there a roadmap for how long these free versions will remain officially available ? * Are there issues compiling 3rd party libraries with it ? E.g. the numeric and science stacks, the web stacks, the deployment stacks, etc. * What license terms will the new version have ? E.g. GPL compatibility issues, weird exceptions, * What will the pricing structure look like ? While core devs will get free MSDN licenses, most other 3rd party providers will have to buy licenses for the compiler, unless they can use the free versions. An alternative would be targeting VC13 instead of VC14, in case it has good answers for the above questions. It's been around for a year now, so there should be more experience available with this version. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 24 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-09-27: PyDDF Sprint 2014 ... 3 days to go 2014-09-30: Python Meeting Duesseldorf ... 6 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: ht
Re: [Python-Dev] 3.5 release schedule PEP
On Wed, 24 Sep 2014 17:12:35 +1000 Nick Coghlan wrote: > On 24 Sep 2014 15:15, "Tim Golden" wrote: > > > > On 23/09/2014 18:05, Steve Dower wrote: > >> > >> I'm also considering/experimenting with installing into "Program > >> Files" by default, but I suspect that isn't going to work out yet. > > > > > > I'd like to see that go forward: I think it's increasingly difficult to > justify Python's position at c:\pythonxx. But it does run the risk of > > breaking All The Things. When it was discussed, people spoke about > > symlinks (or hardlinks / junctions / whatever) in the appropriate > > places to support hardcoded paths, but I don't know how feasible > > that will turn out to be. > > It might be better to offer that as a supported option in 3.5, and then > make it the default in 3.6. I would be surprised if this weren't already a supported option. Decent Windows installers generally allow you to override the installation path (it's been a while I haven't used the Windows Python installer, sorry). I think making the move in 3.5 would be a good idea. Experts can override the installation path and choose C:\PythonXY. There's no actual breakage since the path changes for every major release, anyway (i.e. people would have had to change the path from "C:\Python34" to "C:\Python35"; instead, they will have to change it to "C:\Program Files\Python35"). Regards Antoine. ___ 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] 3.5 release schedule PEP
2014-09-23 2:22 GMT+02:00 Donald Stufft : <> I think we need a Python 3.5 Release Schedule PEP. >> >> Just checked it in as PEP 478. It should show up here in a few minutes: >> >> http://legacy.python.org/dev/peps/pep-0478/ >> Comments? > > It says 3.4.0 all through it. It was too distrubing to read "3.4" in the "3.5" schedule. I modified the PEP directly, sorry Larry. Victor ___ 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] 3.5 release schedule PEP
On 09/24/2014 10:00 PM, Nick Coghlan wrote: Subject: Re: [Python-Dev] 3.5 release schedule PEP On 24 Sep 2014 15:15, "Tim Golden" wrote: > > On 23/09/2014 18:05, Steve Dower wrote: >> I'm also considering/experimenting with installing into "Program >> Files" by default, but I suspect that isn't going to work out yet. > > I'd like to see that go forward: I think it's increasingly difficult to justify Python's position at c:\pythonxx. But it does run the risk of > breaking All The Things. It might be better to offer that as a supported option in 3.5, and then make it the default in 3.6. That will offer a couple of years to work out the issues, rather than a few months. Hi all, ProgramFiles was the default in Python 1.X. It has been a supported option for just shy of 15 years on 2.X... most if not all the bugs (setuptools) were fixed a decade ago, and right now thousands, if not millions of people are running it under Program Files right now. I can vouch for several thousand because a company I work for distributes Python and pip there for its customers all around the world w/o issue. I've never once encountered a bug due to install to ProgramFiles, or heard of anyone who has, and have been using Python for everything since the year 2000. If any rare bugs happen to surface, they can likely be fixed or replaced with a line of code, or worked around by installing elsewhere. The potential existence of such bugs isn't enough reason to stay stuck in 1990 while leaving users vulnerable to tampering attacks for another few years. -Mike ___ 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] 3.5 release schedule PEP
On 24 September 2014 14:16, Mike Miller wrote: > It has been a supported option for just shy of 15 years on 2.X... most if > not all the bugs (setuptools) were fixed a decade ago, and right now > thousands, if not millions of people are running it under Program Files > right now. I can vouch for several thousand because a company I work for > distributes Python and pip there for its customers all around the world w/o > issue. One thing that I presume would be an issue. Isn't Program Files protected in newer versions of Windows? I haven't tested this myself, so I may be wrong about this. So take the following with a pinch of salt. Assuming so, that means that if Python is installed there, the standard "pip install XXX" would not work unless run in an elevated shell. We are currently trying to focus on a unified message for how users should install distributions from PyPI, by using pip install. I'm not sure it's a good idea to complicate that message yet by adding provisos about managing the system Python (which is the only one most Windows users will use). I know this is only the same situation as Unix users have, but Windows users don't have a distro offering packaged versions of PyPI modules. I also know we should be moving towards promoting --user, but I don't think we're quite ready for that yet. And my speculation doesn't compete with your real-life experience, certainly. But I would suggest carefully checking before making the switch. 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] 3.5 release schedule PEP
Most Windows setup are desktop configured with a single user. I would not be shocked if pip installs modules only for the current user by default. Maybe it could be an option in Python installer (pip system wide or user). Victor Le mercredi 24 septembre 2014, Paul Moore a écrit : > On 24 September 2014 14:16, Mike Miller > wrote: > > It has been a supported option for just shy of 15 years on 2.X... most > if > > not all the bugs (setuptools) were fixed a decade ago, and right now > > thousands, if not millions of people are running it under Program Files > > right now. I can vouch for several thousand because a company I work for > > distributes Python and pip there for its customers all around the world > w/o > > issue. > > One thing that I presume would be an issue. Isn't Program Files > protected in newer versions of Windows? I haven't tested this myself, > so I may be wrong about this. So take the following with a pinch of > salt. > > Assuming so, that means that if Python is installed there, the > standard "pip install XXX" would not work unless run in an elevated > shell. We are currently trying to focus on a unified message for how > users should install distributions from PyPI, by using pip install. > I'm not sure it's a good idea to complicate that message yet by adding > provisos about managing the system Python (which is the only one most > Windows users will use). > > I know this is only the same situation as Unix users have, but Windows > users don't have a distro offering packaged versions of PyPI modules. > I also know we should be moving towards promoting --user, but I don't > think we're quite ready for that yet. And my speculation doesn't > compete with your real-life experience, certainly. But I would suggest > carefully checking before making the switch. > > Paul > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%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] 3.5 release schedule PEP
On Wed, 24 Sep 2014 21:32:52 +0200 Victor Stinner wrote: > Most Windows setup are desktop configured with a single user. I would not > be shocked if pip installs modules only for the current user by default. > Maybe it could be an option in Python installer (pip system wide or user). pip install --user ___ 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] 3.5 release schedule PEP
> Paul Moore wrote: > On 24 September 2014 14:16, Mike Miller wrote: >> It has been a supported option for just shy of 15 years on 2.X... >> most if not all the bugs (setuptools) were fixed a decade ago, and >> right now thousands, if not millions of people are running it under >> Program Files right now. I can vouch for several thousand because a >> company I work for distributes Python and pip there for its customers >> all around the world w/o issue. > > One thing that I presume would be an issue. Isn't Program Files protected in > newer versions of Windows? I haven't tested this myself, so I may be wrong > about > this. So take the following with a pinch of salt. It's protected very well in newer versions. You typically need to be an administrator AND have opted in to being able to modify system files without warning. > Assuming so, that means that if Python is installed there, the standard "pip > install XXX" would not work unless run in an elevated shell. We are currently > trying to focus on a unified message for how users should install > distributions > from PyPI, by using pip install. > I'm not sure it's a good idea to complicate that message yet by adding > provisos about managing the system Python (which is the only one most Windows > users will use). This is my main concern. Until pip install --user is the default (or the fallback if there are no write permissions on the destination), a default that locks users out of the simplest PyPI experience is a genuine problem. Yes, users can elevate to run pip, but I'd prefer pip to use elevation if it has it and to use per-user if not. There also isn't a great story for per-user Python installs on Windows, but that becomes fairly cheap with the installer rewrite. > I know this is only the same situation as Unix users have, but Windows users > don't have a distro offering packaged versions of PyPI modules. > I also know we should be moving towards promoting --user, but I don't think > we're quite ready for that yet. And my speculation doesn't compete with your > real-life experience, certainly. But I would suggest carefully checking before > making the switch. A good reason to decide early on a change like this, or at least to promote it as an option in 3.5 and make it the default in 3.6. Cheers, Steve > 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] 3.5 release schedule PEP
> On Sep 24, 2014, at 4:24 PM, Steve Dower wrote: > >> Paul Moore wrote: >> On 24 September 2014 14:16, Mike Miller wrote: >>> It has been a supported option for just shy of 15 years on 2.X... >>> most if not all the bugs (setuptools) were fixed a decade ago, and >>> right now thousands, if not millions of people are running it under >>> Program Files right now. I can vouch for several thousand because a >>> company I work for distributes Python and pip there for its customers >>> all around the world w/o issue. >> >> One thing that I presume would be an issue. Isn't Program Files protected in >> newer versions of Windows? I haven't tested this myself, so I may be wrong >> about >> this. So take the following with a pinch of salt. > > It's protected very well in newer versions. You typically need to be an > administrator AND have opted in to being able to modify system files without > warning. > >> Assuming so, that means that if Python is installed there, the standard "pip >> install XXX" would not work unless run in an elevated shell. We are currently >> trying to focus on a unified message for how users should install >> distributions >> from PyPI, by using pip install. >> I'm not sure it's a good idea to complicate that message yet by adding >> provisos about managing the system Python (which is the only one most Windows >> users will use). > > This is my main concern. Until pip install --user is the default (or the > fallback if there are no write permissions on the destination), a default > that locks users out of the simplest PyPI experience is a genuine problem. > Yes, users can elevate to run pip, but I'd prefer pip to use elevation if it > has it and to use per-user if not. > > There also isn't a great story for per-user Python installs on Windows, but > that becomes fairly cheap with the installer rewrite. > >> I know this is only the same situation as Unix users have, but Windows users >> don't have a distro offering packaged versions of PyPI modules. >> I also know we should be moving towards promoting --user, but I don't think >> we're quite ready for that yet. And my speculation doesn't compete with your >> real-life experience, certainly. But I would suggest carefully checking >> before >> making the switch. > > A good reason to decide early on a change like this, or at least to promote > it as an option in 3.5 and make it the default in 3.6. One thing about *nix is even though you can’t write to your normal Python install location without root, invoking pip with permissions (assuming you have them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows have an equivalent or do you need to launch a whole new shell? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] 3.5 release schedule PEP
Donald Stufft wrote: > One thing about *nix is even though you can’t write to your normal Python > install location without root, invoking pip with permissions (assuming you > have > them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows > have > an equivalent or do you need to launch a whole new shell? Unfortunately not. The "easy way" is for the executable to declare that it needs administrative privileges, and then the OS will take over and let you approve/reject/sign-in/etc. according to your settings. I don't believe this is the right solution anyway, as very many Windows users won't be able to do this (particularly in IT managed environments). Having 'pip install' do a per-user install automatically is something that will actually work, at the cost/benefit of not affecting other users. 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
Re: [Python-Dev] 3.5 release schedule PEP
Thanks for the insights, Steve. More below... On 24.09.2014 18:52, Steve Dower wrote: > M.-A. Lemburg wrote: >> >> I'd rather be conservative here and wait for another Python release before >> switching VC versions. There are a few important questions that need answers >> before we can consider a new VC version: >> >> * Will there be free versions available ? >> >> * Will those free editions include the 64-bit compilers ? >> >> * Will those free editions include the optimizing compilers ? >> >> * Is there a roadmap for how long these free versions will remain >> officially available ? >> >> * Are there issues compiling 3rd party libraries with it ? >> >> E.g. the numeric and science stacks, the web stacks, >> the deployment stacks, etc. >> >> * What license terms will the new version have ? >> >> E.g. GPL compatibility issues, weird exceptions, >> >> * What will the pricing structure look like ? >> >> While core devs will get free MSDN licenses, most other 3rd party >> providers will have to buy licenses for the compiler, unless >> they can use the free versions. >> >> An alternative would be targeting VC13 instead of VC14, in case it has good >> answers for the above questions. It's been around for a year now, so there >> should be more experience available with this version. > > (Nit - it's actually VC12 a.k.a. "Visual Studio 2013" - VC13 was skipped. > This is what happens when you have separate engineering and marketing teams > :) ) Ah, ok :-) > I don't have good answers to all of these yet, but none of them are going to > be any worse than for VC12. I've forwarded these questions to the people on > the VC team who do get to choose the answers, and while I'm not expecting to > hear specifics back from them, they are at least aware of the concerns and > how important their product is to our community. > > There will be free versions available, but I don't know what format they'll > be in. Those free editions should include identical compilers to the paid > ones - the cases where that hasn't been true have been bugs or due to > assumptions that were proven to be incorrect. > > The main improvement in this version is that all versions from VC14 should be > binary compatible, and so there will always be a free compiler, but it may be > VC15/16/etc. and not VC14. That's good news. > There are certainly issues with 3rd party libraries, largely because all > projects have a tendency to take dependencies on compiler/library internals. > OpenSSL, for example, redefines the stdout/in/err macros based on the VC > version, but the new definitions are no longer valid with VC14, and so they > are fixing that. Python itself has a few issues that I have already fixed in > my branch. There will certainly be other issues, but an advantage of starting > early is that bugs in the compiler itself can be fixed in the compiler. > > The license should not change significantly from previous versions. GPL > incompatibilities are because the GPL wants to be incompatible with licenses > based on different ideologies - AFAIK there's never been anything in the VC > licenses preventing whatever redistribution license you like. As example: there once was a special clause which explicitly disallowed "Excluded License[s]" to be used together with VC redistibutable files. I think this is no longer the case, but there may be new things in the EULAs. > Part of my improvements to /PCBuild will help avoid the need for Visual > Studio entirely, but the free versions should always be sufficient for > building and debugging. I have no insight or control over the pricing > structure. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 24 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-09-27: PyDDF Sprint 2014 ... 3 days to go 2014-09-30: Python Meeting Duesseldorf ... 6 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] 3.5 release schedule PEP
> Mike Miller wrote: > Paul Moore wrote: >>> One thing that I presume would be an issue. Isn't Program Files >>> protected in newer versions of Windows? > > Yes, that's the feature that protects from malicious users/code editing > "import > os" to run "format c:\", spam your address book, or look for credit card > numbers, etc. > > It is the same on Mac and other Unix systems, even Windows since Vista came > out, > almost 10 years ago. > >> >> This is my main concern. Until pip install --user is the default (or >> the fallback if there are no write permissions on the destination), >>> real-life experience, certainly. But I would suggest carefully >>> checking before making the switch. > > Windows users know how to elevate now, especially developer types. Sure, but there are plenty of not-quite developer types using Python, plenty using locked down machines, and plenty who simply don't trust arbitrary code when it wants to elevate. The ability to become an admin does not preclude the need to support non-admin users. > It should be billed as a "feature for your protection" not something to be > feared. Microsoft decided security was worth the pain of changing over its > billions of users. Why not Python? > > In my experience pip --user works just fine also. We use it on our unmanned > media players successfully. This is good to know. Maybe we aren't as far away as we think. > We also write Windows services, which run under a system account, where it is > imperative everything is running from a secure file system. > >> A good reason to decide early on a change like this, >> or at least to promote it as an option in 3.5 and make it the default in 3.6. > > It's already an option! It always has been --> Custom install. I can't > remember > a time when it didn't work perfectly. Agreed. I mean it'll become an obvious option (one of the radio buttons at the start), and eventually the default option. As a slight aside, do you enable the option to compile PYC/PYO files on install? Unless your users are running as admin, you won't get caching on these for the stdlib when it's installed into Program Files. Cheers, Steve > -Mike ___ 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] 3.5 release schedule PEP
On 09/25/2014 08:50 AM, Steve Dower wrote: Unfortunately not. The "easy way" is for the executable to declare that it needs administrative privileges, and then the OS will take over and let you approve/reject/sign-in/etc. according to your settings. There is the runas command, though it could be easier to use. There is also a third-part "sudo" clone. I don't believe this is the right solution anyway, as very many Windows users won't be able to do this (particularly in IT managed environments). Having 'pip install' do a per-user install automatically is something that will actually work, at the cost/benefit of not affecting other users. Shoul mention this won't take any choices away from users, such as IT managed environs, they could still install wherever they need to. I understand pip is not actually bundled with Python, just an installer script. That means it is decoupled from changes in the Python installer. Pypa can have pip default to, or fall back to --user later if it decides it is a good idea. -Mike ___ 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] 3.5 release schedule PEP
Paul Moore wrote: One thing that I presume would be an issue. Isn't Program Files protected in newer versions of Windows? Yes, that's the feature that protects from malicious users/code editing "import os" to run "format c:\", spam your address book, or look for credit card numbers, etc. It is the same on Mac and other Unix systems, even Windows since Vista came out, almost 10 years ago. This is my main concern. Until pip install --user is the default (or the fallback if there are no write permissions on the destination), real-life experience, certainly. But I would suggest carefully checking before making the switch. Windows users know how to elevate now, especially developer types. It should be billed as a "feature for your protection" not something to be feared. Microsoft decided security was worth the pain of changing over its billions of users. Why not Python? In my experience pip --user works just fine also. We use it on our unmanned media players successfully. We also write Windows services, which run under a system account, where it is imperative everything is running from a secure file system. A good reason to decide early on a change like this, > or at least to promote it as an option in 3.5 and make it the default in 3.6. It's already an option! It always has been --> Custom install. I can't remember a time when it didn't work perfectly. -Mike ___ 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] 3.5 release schedule PEP
On 09/25/2014 08:43 AM, Donald Stufft wrote: One thing about *nix is even though you can’t write to your normal Python install location without root, invoking pip with permissions (assuming you have them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows have an equivalent or do you need to launch a whole new shell? There is the "runas" command, though it is a tad harder to use. There is a third-party windows sudo command also that works as you'd expect. -Mike ___ 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] 3.5 release schedule PEP
On 24 September 2014 22:29, Steve Dower wrote: >> In my experience pip --user works just fine also. We use it on our unmanned >> media players successfully. > > This is good to know. Maybe we aren't as far away as we think. Indeed. Moving towards having --user as the norm is definitely something we want to look at for pip. One of the biggest concerns is how well-exercised the whole user site directory area is in practice. Reports like this are great for confirming that it's a viable approach. 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] 3.5 release schedule PEP
On Wed, 24 Sep 2014 22:56:20 +0100 Paul Moore wrote: > On 24 September 2014 22:29, Steve Dower wrote: > >> In my experience pip --user works just fine also. We use it on our unmanned > >> media players successfully. > > > > This is good to know. Maybe we aren't as far away as we think. > > Indeed. Moving towards having --user as the norm is definitely > something we want to look at for pip. One of the biggest concerns is > how well-exercised the whole user site directory area is in practice. What do you mean by well-exercised? Regards Antoine. ___ 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] 3.5 release schedule PEP
M.-A. Lemburg wrote: > > I'd rather be conservative here and wait for another Python release before > switching VC versions. There are a few important questions that need answers > before we can consider a new VC version: > > * Will there be free versions available ? > > * Will those free editions include the 64-bit compilers ? > > * Will those free editions include the optimizing compilers ? > > * Is there a roadmap for how long these free versions will remain > officially available ? > > * Are there issues compiling 3rd party libraries with it ? > > E.g. the numeric and science stacks, the web stacks, > the deployment stacks, etc. > > * What license terms will the new version have ? > > E.g. GPL compatibility issues, weird exceptions, > > * What will the pricing structure look like ? > > While core devs will get free MSDN licenses, most other 3rd party > providers will have to buy licenses for the compiler, unless > they can use the free versions. > > An alternative would be targeting VC13 instead of VC14, in case it has good > answers for the above questions. It's been around for a year now, so there > should be more experience available with this version. (Nit - it's actually VC12 a.k.a. "Visual Studio 2013" - VC13 was skipped. This is what happens when you have separate engineering and marketing teams :) ) I don't have good answers to all of these yet, but none of them are going to be any worse than for VC12. I've forwarded these questions to the people on the VC team who do get to choose the answers, and while I'm not expecting to hear specifics back from them, they are at least aware of the concerns and how important their product is to our community. There will be free versions available, but I don't know what format they'll be in. Those free editions should include identical compilers to the paid ones - the cases where that hasn't been true have been bugs or due to assumptions that were proven to be incorrect. The main improvement in this version is that all versions from VC14 should be binary compatible, and so there will always be a free compiler, but it may be VC15/16/etc. and not VC14. There are certainly issues with 3rd party libraries, largely because all projects have a tendency to take dependencies on compiler/library internals. OpenSSL, for example, redefines the stdout/in/err macros based on the VC version, but the new definitions are no longer valid with VC14, and so they are fixing that. Python itself has a few issues that I have already fixed in my branch. There will certainly be other issues, but an advantage of starting early is that bugs in the compiler itself can be fixed in the compiler. The license should not change significantly from previous versions. GPL incompatibilities are because the GPL wants to be incompatible with licenses based on different ideologies - AFAIK there's never been anything in the VC licenses preventing whatever redistribution license you like. Part of my improvements to /PCBuild will help avoid the need for Visual Studio entirely, but the free versions should always be sufficient for building and debugging. I have no insight or control over the pricing structure. Cheers, Steve > -- > Marc-Andre Lemburg > eGenix.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] Python 3.4.2rc1 Mac OS X
On Tue, Sep 23, 2014 at 10:27 AM, Ned Deily wrote: > Thanks for the feedback, Carol. Let us know via bugs.python.org of any > issues you see. BTW, the new installer format will be coming to Python > 2.7.9 as well. > Are the supported platforms going to be the same? i.e.: 10.3+ -- Intel32+PPC32 (Or is this deprecated already?) 10.6+ -- Intel32_Intel64 I'm actually wondering if it's time for a pure Intel64, probably 10.7+ Building extensions for Universal builds and older OS versions really is a pain... -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 [email protected] ___ 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] 3.5 release schedule PEP
On Thu, Sep 25, 2014 at 6:50 AM, Steve Dower wrote: > Donald Stufft wrote: >> One thing about *nix is even though you can’t write to your normal Python >> install location without root, invoking pip with permissions (assuming you >> have >> them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows >> have >> an equivalent or do you need to launch a whole new shell? > > Unfortunately not. The "easy way" is for the executable to declare that it > needs administrative privileges, and then the OS will take over and let you > approve/reject/sign-in/etc. according to your settings. When you say the executable declares this, is that a static (compile/link time) declaration, or a run-time one? That is, could pip defer the declaration until it's parsed its command line args and decided that it'll be installing into the system directory, but NOT make that declaration if it's given --user, or if it's running inside a venv, or anything else that means it doesn't need that power? If so, that could actually be a very powerful feature: a user without admin privs (or choosing not to exercise them) is still able to install into a venv, but if s/he forgets to activate the venv, the "hey, I want to modify system files" prompt will be the alarm that says the situation is not what was expected. That's what happens on my Linux system - I get errors back if I don't use sudo, but in a venv, everything works without being root. 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] 3.5 release schedule PEP
Yes, we enable the compile script. As we require admin rights to install Python and system (not user) modules with pip, the stdlib .pycs do get created under ProgramFiles at install time. There might well be a situation where a system pipped module doesn't get compiled, but to be honest the difference is negligible on modern machines, those needed to run a supported Windows. I suppose this issue could be improved in the future by caching unwritable system .pyc in a user folder, however it feels like a micro-optimization that shouldn't hold up the change. -Mike On 09/25/2014 09:29 AM, Steve Dower wrote: As a slight aside, do you enable the option to compile PYC/PYO files on install? Unless your users are running as admin, you won't get caching on these for the stdlib when it's installed into Program Files. Cheers, Steve -Mike ___ 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] 3.5 release schedule PEP
On 9/24/2014 6:59 PM, Chris Angelico wrote: That is, could pip defer the declaration until it's parsed its command line args and decided that it'll be installing into the system directory, but NOT make that declaration if it's given --user, or if it's running inside a venv, or anything else that means it doesn't need that power? Other programs do it. ___ 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] 3.5 release schedule PEP
On 09/23/2014 06:48 PM, Nick Coghlan wrote: On 24 September 2014 03:05, Steve Dower wrote: I'd like to move the Windows versions onto the next release of VC (currently "VC 14" until the branding team figures out what to call it). There isn't a promised RTM date for VC 14 yet, so it looks like the best available compiler by Beta 1 will be a "Go Live" RC. (The "Go Live" marking basically means "we think this is ready for use, but expect a round of minor updates/fixes soon - the compiler is least likely to be updated, my guess is that it'll be Visual Studio UI mostly). It's ultimately up to Larry as RM, but I'd personally favour targeting the newer compiler and runtime, even with the slight risk of potentially needing to slip our schedule. There's also a fair amount of wiggle room between the first beta and the first release candidate. First, let me say that I'm absolutely willing to listen to the choir of expert modern Windows developers. I haven't done much of anything with Windows since 2007, and I don't claim to be current. So if I'm being wrong-headed on this, you're invited to educate me. Also, having a retooled CRTL with forwards-compatible interfaces indeed sounds awesome, and is a worthy goal. With all that said: I'm comfortable shipping everything up to RCs on a beta compiler. But once we hit RC1, I assert we *must* be using a released product. Release Candidates are supposed to be viable, releasable software, and surely we wouldn't ship 3.5.0 on a beta compiler. Therefore: if VC14 doesn't ship by 3.5 RC1, currently set at August 5, 2015, I decree we have to ship 3.5 with the previous version. Reasonable? //arry/ ___ 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] 3.5 release schedule PEP
On 09/24/2014 08:04 AM, Victor Stinner wrote: It was too distrubing to read "3.4" in the "3.5" schedule. I modified the PEP directly, sorry Larry. No sweat. I would have fixed it myself, but yesterday was a big travel day. Thanks for fixing it! //arry/ ___ 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] 3.5 release schedule PEP
On 25 September 2014 02:08, Antoine Pitrou wrote: >> Indeed. Moving towards having --user as the norm is definitely >> something we want to look at for pip. One of the biggest concerns is >> how well-exercised the whole user site directory area is in practice. > > What do you mean by well-exercised? Basically, although --user is available in pip (and the underlying facilities in Python have been around for some time), it's difficult to gauge how many people are using them, and as a result what level of testing has happened in real-life situations. There's probably no way to improve that much other than by making --user the default and waiting for reports of any issues, but feedback like Mike's adds a certain level of confidence that there are no significant problems. 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
