Re: [Python-Dev] draft PEP: virtual environments
Antoine Pitrou solipsis at pitrou.net writes: I don't understand why a zip file makes this easier (especially the update selectively part). Not a zip file specifically - just a binary stream which organises scripts to be installed. If each class in a hierarchy has access to a binary stream, then subclasses have access to the streams for base classes as well as their own stream, and can install selectively from base class streams and their own stream. class Base: scripts = ... # zip stream containing scripts A, B def install_scripts(self, stream): # ... def setup_scripts(self): self.install_scripts(self.scripts) class Derived: scripts = ... # zip stream containing modified script B, new script C def setup_scripts(self): self.install_scripts(Base.scripts) # adds A, B self.install_scripts(self.scripts) # adds C, overwrites B I'm not saying you couldn't do this with e.g. directory trees; it just seems neater to have the scripts in a black box once they're deployed, with a zip file representing that black box. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
Paul Moore p.f.moore at gmail.com writes: Hang on. I'm talking here about repackaging the binary files in the MSI file for use in a pysetup install invocation. As pysetup has no GUI, and doesn't integrate with Add/Remove, there's no issue here. If you want a GUI and Add/Remove integration, just run the MSI. Or am I missing something? We seem to be at cross purposes here, I suspect I'm missing your point. As you say later in your post, we're probably just coming at this from two different perspectives. I think you mentioned the possible need to install to a temporary location just to extract files from the CAB; then you would presumably need to uninstall again to remove the Add/Remove Programs entry created when you installed to the temporary location (or else I misunderstood your meaning here). It would be important to retain the flexibility offered by setup.cfg hooks, as I don't believe any out-of-the-box approach will work for the range of use cases on Windows (think Powershell scripts, Visio templates and other Microsoft Office integration components). Why? Again, if this is purely as a means to consume bdist_xxx files, then the only flexibility needed is enough to cater for any variations in data stored in the bdist_xxx format. The wininst format is easy here - it has directories PLATLIB, PURELIB, DATA, SCRIPTS and HEADERS (corresponding to the installation --install-xxx parameters) and that's all. As long as the module is flexible enough to deal with that, it can read anything bdist_wininst can produce. My point is really that a one-size-fits-all DATA location is unlikely to cater to all use cases. The flexibility offered by setup.cfg together with hooks gets around the limitation of a single location for data. Ah, I think I see what you are getting at. If someone uses the new features and flexibility of packaging to create a fancy custom install scheme, how do they bundle up a binary distribution from that? My (current) answer is that I don't know. The packaging module as it stands only offers the legacy bdist_xxx formats, so the answer is run pysetup run bdist_wininst on it. If that breaks (as it is likely to - wininst format isn't very flexible) then tough, you're out of luck. Yes, that's what I was getting at. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2011 5:14 PM, Tres Seaver wrote: On 10/30/2011 02:04 PM, Ned Deily wrote: In article cacac1f-cmbkryagzrcawdndm7-vn4yjo99fbd9vvccmbhcv...@mail.gmail.com, Paul Moore p.f.mo...@gmail.com wrote: I'd like to reopen the discussions on how the new packaging module will handle/support binary distributions in Python 3.3. The previous thread (see http://mail.python.org/pipermail/python-dev/2011-October/113956.html) included a lot of good information and discussion, but ultimately didn't reach any firm conclusions. First question - is this a Windows only problem, or do Unix/MacOS users want binary support? My feeling is that it's not an issue for them, at least not enough that anyone has done anything about it in the past, so I'll focus on Windows here. I haven't been following this discussion that closely but I'm rather surprised that the need for binary distributions for Python packages on non-Windows platforms would be in question. Just as on Windows, it's not a given that all Unix or Mac OS X end-user systems will have the necessary development tools installed (C compiler, etc) to build C extension modules. Today, the most platform-independent way of distributing these are with binary eggs: the individual binary eggs are, of course, not platform-independent but the distribution and installation mechanism is or should be. Sure, there are other ways, like pushing the problem back to the OS distributor (e.g. Debian, Red Hat, et al) or, as in the case of Mac OS X where there isn't a system package manager in the same sense, to a third-party package distributor (like MacPorts, Homebrew, or Fink). Or you can produce platform-specific installers for each platform which also seems heavy-weight. I don't pushing it back to the OS vendor solves the problem. Say I want to install these binary packages with buildout: How would it go about consuming an RPM to install in an isolated buildout directory? Has anyone analyzed the current packages on PyPI to see how many provide binary distributions and in what format? Practically speaking, nobody but Windows consumers *needs* binary packages on PyPI: even if the target (production) box is crippled^Wstripped of its compiler, such environments always have staging hosts which can be used to build binary packages for internal distribution. It might be true that such systems don't need binary packages on PyPI, but the original question is about binary package support for the packaging module on non-Windows systems. I think the answer is clearly yes: I have such systems without compilers. If I build packages on a staging server, I would want to put them on an internal PyPI-like server, for consumption by packaging. So packaging would need to consume these binary packages. Eric. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOrnFiAAoJENxauZFcKtNxLG0H/03d0uRXw/MvlCA9q92OlwWk +X2PqpZ/F5aFBuN3lsichr/qLiHm69tNu3K++JyLXypT7hzbiB8QEbVUn5Z8X2ds is/6wKIX5Hmd//UlX+VtlYZQSXd/1k7FbqFY0CPTRFGrE+I9ipfCnO3h1OiBwHpY eejoR4Lr/6MXZ+v7DdlyRC9mWZV/uNKnR0ec5ABbQIEC13/j91gR/57ua/ryhRmT hco4ssRSP9pqO058aVJ1ivw2q+9364f7DgWynafRjkrcTy80gZ90LTz7WtteeFPr QO2yFW8ZI0UsxUxNRsDBj1N91AVHngU6HJa1evgegUPRjl94neSQLLWLla37qfQ= =2b7E -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
Am 31.10.2011 09:07, schrieb Vinay Sajip: Paul Moore p.f.moore at gmail.com writes: Hang on. I'm talking here about repackaging the binary files in the MSI file for use in a pysetup install invocation. As pysetup has no GUI, and doesn't integrate with Add/Remove, there's no issue here. If you want a GUI and Add/Remove integration, just run the MSI. Or am I missing something? We seem to be at cross purposes here, I suspect I'm missing your point. As you say later in your post, we're probably just coming at this from two different perspectives. I think you mentioned the possible need to install to a temporary location just to extract files from the CAB; then you would presumably need to uninstall again to remove the Add/Remove Programs entry created when you installed to the temporary location (or else I misunderstood your meaning here). This presumption is false (as is the claim that you need to install the MSI to get at the files). It's quite possible to extract the files from the MSI without performing the installation. There are actually two ways to do that: a) perform an administrative installation, which unpacks the files to disk but doesn't actually perform any installation procedure, or b) use the MSI API to extract first the CAB file, and then the files in the CAB file. This would be a bit work to do if you want to find out the full path names of the individual files, but it could work in theory. Why? Again, if this is purely as a means to consume bdist_xxx files, then the only flexibility needed is enough to cater for any variations in data stored in the bdist_xxx format. The wininst format is easy here - it has directories PLATLIB, PURELIB, DATA, SCRIPTS and HEADERS (corresponding to the installation --install-xxx parameters) and that's all. As long as the module is flexible enough to deal with that, it can read anything bdist_wininst can produce. My point is really that a one-size-fits-all DATA location is unlikely to cater to all use cases. The flexibility offered by setup.cfg together with hooks gets around the limitation of a single location for data. I'm sure bdist_wininst can be augmented to support arbitrary base prefixes (assuming that is the flexibility you talk about). It would just need a list of what directory names are prefixes, The MSI format is designed to provide exactly that flexibility of arbitrarily mapping source folders to destination folders during installation. bdist_msi would just need to be taught to interpret setup.cfg files. Ah, I think I see what you are getting at. If someone uses the new features and flexibility of packaging to create a fancy custom install scheme, how do they bundle up a binary distribution from that? My (current) answer is that I don't know. The packaging module as it stands only offers the legacy bdist_xxx formats, so the answer is run pysetup run bdist_wininst on it. If that breaks (as it is likely to - wininst format isn't very flexible) then tough, you're out of luck. Yes, that's what I was getting at. Hmm. You are just describing a bug, not an inherent limitation. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
On 31 October 2011 10:42, Martin v. Löwis mar...@v.loewis.de wrote: Am 31.10.2011 09:07, schrieb Vinay Sajip: This presumption is false (as is the claim that you need to install the MSI to get at the files). It's quite possible to extract the files from the MSI without performing the installation. There are actually two ways to do that: a) perform an administrative installation, which unpacks the files to disk but doesn't actually perform any installation procedure, or b) use the MSI API to extract first the CAB file, and then the files in the CAB file. This would be a bit work to do if you want to find out the full path names of the individual files, but it could work in theory. Yes, I'm currently doing an administrative install via msiexec to get the files out. It's simple enough to do. My point is really that a one-size-fits-all DATA location is unlikely to cater to all use cases. The flexibility offered by setup.cfg together with hooks gets around the limitation of a single location for data. I'm sure bdist_wininst can be augmented to support arbitrary base prefixes (assuming that is the flexibility you talk about). It would just need a list of what directory names are prefixes, The MSI format is designed to provide exactly that flexibility of arbitrarily mapping source folders to destination folders during installation. bdist_msi would just need to be taught to interpret setup.cfg files. Agreed - the one size fits all data location is a limitation. I'm not sure that in practical terms it is a big issue, though - it's been like that since the wininst format was designed, and nobody has ever complained. There are certainly cases where packages have needed to implement more or less clumsy workarounds (for example, not including documentation in binary distributions) but it's obviously never been enough of an issue to prompt people to fix it. The egg format has the same limitation, as far as I'm aware, so clearly even the eggs solve everything crowd don't feel it's a real issue :-) Ah, I think I see what you are getting at. If someone uses the new features and flexibility of packaging to create a fancy custom install scheme, how do they bundle up a binary distribution from that? My (current) answer is that I don't know. The packaging module as it stands only offers the legacy bdist_xxx formats, so the answer is run pysetup run bdist_wininst on it. If that breaks (as it is likely to - wininst format isn't very flexible) then tough, you're out of luck. Yes, that's what I was getting at. Hmm. You are just describing a bug, not an inherent limitation. Precisely. And it's a bug that no-one has felt the need to fix in many years. The flexibility is not new - distutils had at least as much flexibility if not more. I'd love to see a binary format that was as flexible and powerful as building from source, which allowed OS integration where the user wanted it while still supporting venvs and non-system installations, and which was widely adopted by distribution authors. Oh, and can I have a pony? :-) Sadly, I don't have the time or understanding of the various requirements to deliver something like that. Realistically, I'd just like to be able to benefit from the generosity of existing distribution authors who make compiled versions of their code available, however they choose to do so. Hence my current focus on consuming existing formats (and even the bdist_simple proposal/patch was little more than a tidied up bdist_wininst made OS-neutral). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
Paul Moore p.f.moore at gmail.com writes: Agreed - the one size fits all data location is a limitation. I'm not sure that in practical terms it is a big issue, though - it's been like that since the wininst format was designed, and nobody has ever complained. There are certainly cases where packages have needed to implement more or less clumsy workarounds (for example, not including documentation in binary distributions) but it's obviously never been enough of an issue to prompt people to fix it. The egg format has the same limitation, as far as I'm aware, so clearly even the eggs solve everything crowd don't feel it's a real issue Yes, but with setup.py you had the option of running any Python code to move things around using a post-install script, so people could get around those limitations, albeit in a completely ad hoc way. So there was nothing to fix, but no standard way of achieving what you wanted in out-of-the-ordinary scenarios. I'd love to see a binary format that was as flexible and powerful as building from source, which allowed OS integration where the user wanted it while still supporting venvs and non-system installations, and which was widely adopted by distribution authors. Oh, and can I have a pony? Sadly, I don't have the time or understanding of the various requirements to deliver something like that. Well, from the point of view of venvs and PEP 404, it's certainly topical and worth trying to get some traction behind this particular pony. If bdist_pony is easy enough to use and doesn't close any existing doors, then there's no obvious reason why distribution authors wouldn't use it for future releases of their distributions. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
Martin v. Löwis martin at v.loewis.de writes: This presumption is false (as is the claim that you need to install the MSI to get at the files). It's quite possible to extract the files from the MSI without performing the installation. There are actually two ways to do that: a) perform an administrative installation, which unpacks the files to disk but doesn't actually perform any installation procedure, or b) use the MSI API to extract first the CAB file, and then the files in the CAB file. This would be a bit work to do if you want to find out the full path names of the individual files, but it could work in theory. I'd completely forgotten about the administrative installation - thanks for reminding me. The MSI format is designed to provide exactly that flexibility of arbitrarily mapping source folders to destination folders during installation. bdist_msi would just need to be taught to interpret setup.cfg files. I agree in principle, but one thing you get with setup.cfg which seems harder to achieve with MSI is the use of Python to do things at installation time. For example, with setup.cfg hooks, you can use ctypes to make Windows API calls at installation time to decide where to put things. While this same flexibility exists in the MSI format (with custom actions and so forth) it's not as readily accessible to someone who wants to use Python to code this type of installation logic. Hmm. You are just describing a bug, not an inherent limitation. You're right that it's not an inherent limitation, but I'm not sure which bug you're referring to. Do you mean just a current limitation? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2011 05:10 PM, Chris McDonough wrote: Why not modify sys.prefix? - -- As discussed above under `Backwards Compatibility`_, this PEP proposes to add ``sys.site_prefix`` as the prefix relative to which site-package directories are found. This maintains compatibility with the documented meaning of ``sys.prefix`` (as the location relative to which the standard library can be found), but means that code assuming that site-packages directories are found relative to ``sys.prefix`` will not respect the virtual environment correctly. Since it is unable to modify ``distutils``/``sysconfig``, `virtualenv`_ is forced to instead re-point ``sys.prefix`` at the virtual environment. An argument could be made that this PEP should follow virtualenv's lead here (and introduce something like ``sys.base_prefix`` to point to the standard library and header files), since virtualenv already does this and it doesn't appear to have caused major problems with existing code. Another argument in favor of this is that it would be preferable to err on the side of greater, rather than lesser, isolation. Changing ``sys.prefix`` to point to the virtual environment and introducing a new ``sys.base_prefix`` attribute would err on the side of greater isolation in the face of existing code's use of ``sys.prefix``. It would seem to make sense to me to err on the side of greater isolation, introducing sys.base_prefix to indicate the base prefix (as opposed to sys.site_prefix indicating the venv prefix). Bugs introduced via a semi-isolated virtual environment are very difficult to troubleshoot. It would also make changes to existing code unnecessary. I have encountered no issues with virtualenv doing this so far. I'm convinced that this is the better tradeoff. I'll begin working on a branch of the reference implementation that does things this way. Thanks for the feedback. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6uq2IACgkQ8W4rlRKtE2chHQCgik136LkoQ/JE6b3r4astWcog kYYAoN7ESaPlZOaYeok5t0i9hMkb2L4g =/Rn1 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
On Mon, 31 Oct 2011 07:50:24 + (UTC) Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Antoine Pitrou solipsis at pitrou.net writes: I don't understand why a zip file makes this easier (especially the update selectively part). Not a zip file specifically - just a binary stream which organises scripts to be installed. If each class in a hierarchy has access to a binary stream, then subclasses have access to the streams for base classes as well as their own stream, and can install selectively from base class streams and their own stream. Isn't that overengineered? We're talking about a couple of files. It's not even obvious that third-party tools will want to modify them, instead of writing their own (if the venv API is stable, it should be relatively easy). I'm not saying you couldn't do this with e.g. directory trees; it just seems neater to have the scripts in a black box once they're deployed, with a zip file representing that black box. I don't know why it's neater. After all, we install .py files in their original form, not in a zipfile (even though Python supports the latter). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
On Mon, 31 Oct 2011 05:59:09 -0400 Eric V. Smith e...@trueblade.com wrote: It might be true that such systems don't need binary packages on PyPI, but the original question is about binary package support for the packaging module on non-Windows systems. I think the answer is clearly yes: I have such systems without compilers. If I build packages on a staging server, I would want to put them on an internal PyPI-like server, for consumption by packaging. So packaging would need to consume these binary packages. And it's not only compilers, it's also external libraries (which are generally not installed by default). For example, to compile pyOpenSSL, you first need to fetch the OpenSSL development headers. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
Antoine Pitrou solipsis at pitrou.net writes: Isn't that overengineered? We're talking about a couple of files. We're not talking about a lot of code to do this, either - just the interface to the existing code (which is needed anyway to install the minimal scripts in the venv). It's not even obvious that third-party tools will want to modify them, instead of writing their own (if the venv API is stable, it should be relatively easy). Well, virtualenvwrapper is pretty popular addon to virtualenv which delivers additional scripts, even though virtualenv already supplies more scripts than we're proposing to do in the stdlib. Example use cases for such scripts might be things like environment manipulation when environments are activated/deactivated (e.g. for LD_LIBRARY_PATH) - we can't always predict all the different needs that arise, so I'm just leaving the door open to third parties to be able to do what they need. I don't know why it's neater. After all, we install .py files in their original form, not in a zipfile (even though Python supports the latter). Perhaps it's a matter of taste. The files we're talking about are actually data in the context we're discussing. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
On 31 October 2011 14:22, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 31 Oct 2011 05:59:09 -0400 Eric V. Smith e...@trueblade.com wrote: It might be true that such systems don't need binary packages on PyPI, but the original question is about binary package support for the packaging module on non-Windows systems. I think the answer is clearly yes: I have such systems without compilers. If I build packages on a staging server, I would want to put them on an internal PyPI-like server, for consumption by packaging. So packaging would need to consume these binary packages. And it's not only compilers, it's also external libraries (which are generally not installed by default). For example, to compile pyOpenSSL, you first need to fetch the OpenSSL development headers. It sounds to me like there's a clear interest in some level of binary distribution support from packaging. Could anyone comment on whether the current level of support is sufficient? (My instinct says it isn't, but I don't want to put words in people's mouths). If not, a PEP may be the best way to move this forward, but as things stand I'm not entirely clear what that PEP should be proposing. My inclination (to make packaging and pysetup install capable of reading existing binary formats) doesn't seem to be sufficient for most people. Does anyone want to work with me on coming up with a PEP? Paul. PS Should this discussion move somewhere else? Maybe python-ideas or distutils-sig? I'm not sure it's well-formed enough for python-dev at the moment... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2011 04:47 PM, Vinay Sajip wrote: Antoine Pitrou solipsis at pitrou.net writes: It would be even simpler not to process it at all, but install the scripts as-is (without the execute bit) :) Sure, but such an approach makes it difficult to provide a mechanism which is easily extensible; for example, with the current approach, it is straightforward for third party tools to either easily replace completely, update selectively or augment simply the scripts provided by base classes. I don't understand this point either. It seems to me too that having the scripts installed as plain data files inside a package is just as easy or easier for third-party tools to work with flexibly in all of the ways you mention, compared to having them available in any kind of zipped format. The current os.name-based directory structure can still be used, and we can still provide the helper to take such a directory structure and install the appropriate scripts based on os.name. I don't see any advantage to zipping. If done at install-time (which is necessary to make the scripts maintainable in the source tree) it also has the downside of introducing another difficulty in supporting source builds equivalently to installed builds. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6uvkYACgkQ8W4rlRKtE2ezZwCfUv80rp7Vg//zRA471R9JJDlj 83gAn0e9r76c9WkjutLcpbRjeopFkmew =Z0kj -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
Carl Meyer carl at oddbird.net writes: I don't see any advantage to zipping. If done at install-time (which is necessary to make the scripts maintainable in the source tree) it also has the downside of introducing another difficulty in supporting source builds equivalently to installed builds. That's true, I hadn't thought of that. So then it sounds like the thing to do is make venv a package and have the code in venv/__init__.py, then have the scripts in a 'scripts' subdirectory below that. The API would then change to take the absolute pathname of the scripts directory to install from, right? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2011 09:35 AM, Vinay Sajip wrote: That's true, I hadn't thought of that. So then it sounds like the thing to do is make venv a package and have the code in venv/__init__.py, then have the scripts in a 'scripts' subdirectory below that. The API would then change to take the absolute pathname of the scripts directory to install from, right? That sounds right to me. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6uwXEACgkQ8W4rlRKtE2fUQgCfb1Cn7OYZzt3/xoKzmJuCmvbt B9sAn0kuBZzjVImIC1r8Jb506KbsRHBN =lgga -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2011 06:28 AM, Antoine Pitrou wrote: On Sun, 30 Oct 2011 12:10:18 + (UTC) Vinay Sajip vinay_sa...@yahoo.co.uk wrote: We already have Unix shell scripts and BAT files in the source tree. Is it really complicated to maintain these additional shell scripts? Is there a lot of code in them? No, they're pretty small: wc -l gives 76 posix/activate (Bash script, contains deactivate() function) 31 nt/activate.bat 17 nt/deactivate.bat The question is whether we should stop at that, or whether there should be support for tcsh, fish etc. such as virtualenv provides. I don't think we need additional support for more or less obscure shells. Also, if posix/activate is sufficiently well written (don't ask me how :-)), it should presumably be compatible with all Unix shells? I have no problem including the basic posix/nt activate scripts if no one else is concerned about the added maintenance burden there. I'm not sure that my cross-shell-scripting fu is sufficient to write posix/activate in a cross-shell-compatible way; I use bash and am not very familiar with other shells. If it runs under /bin/sh is that sufficient to make it compatible with all Unix shells (for some definition of all)? If so, I can work on this. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6uw80ACgkQ8W4rlRKtE2e0AACcCGqxp/HWxX0UAqtS9W5y+UDr weAAnjF4YdsCUvb4bXFloEGt1b7KlvWB =2bd+ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2011 11:50 AM, Carl Meyer wrote: I have no problem including the basic posix/nt activate scripts if no one else is concerned about the added maintenance burden there. I'm not sure that my cross-shell-scripting fu is sufficient to write posix/activate in a cross-shell-compatible way; I use bash and am not very familiar with other shells. If it runs under /bin/sh is that sufficient to make it compatible with all Unix shells (for some definition of all)? If so, I can work on this. I would say this is a perfect opportunity to delegate, in this case to the devotees of other cults^Wshells than bash. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ux/QACgkQ+gerLs4ltQ7j0wCffLICxbvo9ed0wMhEkn/iFzCj euEAnjvhPOAz09570Xh1PGBcksQ0De4n =YIG0 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
On 31 October 2011 16:08, Tres Seaver tsea...@palladion.com wrote: On 10/31/2011 11:50 AM, Carl Meyer wrote: I have no problem including the basic posix/nt activate scripts if no one else is concerned about the added maintenance burden there. I'm not sure that my cross-shell-scripting fu is sufficient to write posix/activate in a cross-shell-compatible way; I use bash and am not very familiar with other shells. If it runs under /bin/sh is that sufficient to make it compatible with all Unix shells (for some definition of all)? If so, I can work on this. I would say this is a perfect opportunity to delegate, in this case to the devotees of other cults^Wshells than bash. For Windows, can you point me at the nt scripts? If they aren't too complex, I'd be willing to port to Powershell. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
Hi, I'd like to reopen the discussions on how the new packaging module will handle/support binary distributions in Python 3.3. The previous thread (see http://mail.python.org/pipermail/python-dev/2011-October/113956.html) included a lot of good information and discussion, but ultimately didn't reach any firm conclusions. I’m sorry there was no reply from the core group of packaging contributors. I read the messages as they flew by and wanted to reply on a lot of points, but didn’t get the time to do it. I hope the list subscribers won’t mind if I go through the threads in the coming days and make many replies. Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Add a button to the code examples in the doc to show/hide the prompts and
Hi Ezio,
http://hg.python.org/cpython/rev/18bbfed9aafa
user:Ezio Melotti ezio.melo...@gmail.com
summary:
Add a button to the code examples in the doc to show/hide the prompts and
output.
Looks cool! I hope this will stop our use of two or three different
styles for Python code in the docs (doctest-compatible vs.
source-file-style vs. copy-paste-ready) and ultimately help make them
doctest-compatible.
+$(document).ready(function() {
+/* Add a [] button on the top-right corner of code samples to hide
+ * the and ... prompts and the output and thus make the code
+ * copyable. */
I think it would be more user-friendly if the button/trigger would use
real English text like “Hide prompts”/“Show prompts” rather than symbols.
Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): I should be someone
Hi, http://hg.python.org/cpython/rev/6f56e81da8f6 user:Florent Xicluna florent.xicl...@gmail.com summary: I should be someone Without quotation marks, that sounded like a philosophical commit :) Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Code cleanups in stable branches?
Hi, http://hg.python.org/cpython/rev/72de2ac8bb4f branch: 2.7 user:Petri Lehtinen pe...@digip.org date:Sun Oct 30 13:55:02 2011 +0200 summary: Avoid unnecessary recursive function calls (closes #10519) http://hg.python.org/cpython/rev/0694ebb5db99 branch: 2.7 user:Jesus Cea j...@jcea.es date:Mon Oct 31 16:02:12 2011 +0100 summary: Closes #13283: removal of two unused variable in locale.py I thought that patches that clean up code but don’t fix actual bugs were not done in stable branches. Has this changed? (The first commit quoted above may be a performance fix, which would be okay IIRC.) Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Add a button to the code examples in the doc to show/hide the prompts and
Hi Éric,
On 31/10/2011 19.19, Éric Araujo wrote:
Hi Ezio,
http://hg.python.org/cpython/rev/18bbfed9aafa
user:Ezio Melottiezio.melo...@gmail.com
summary:
Add a button to the code examples in the doc to show/hide the prompts and
output.
Looks cool! I hope this will stop our use of two or three different
styles for Python code in the docs (doctest-compatible vs.
source-file-style vs. copy-paste-ready) and ultimately help make them
doctest-compatible.
My main concern about this is that it works only with the HTML doc and
now with the pdf/chm, so converting the examples would make the
situation a bit worse for the pdf/chm users (and also for js-less
users). I think in the examples we should just use what make more sense
-- either copy/paste from an interpreter session when the output is
relevant, copy only the source when it's not, and avoid the hybrid
style (i.e. include the '' and the output but omit the '...').
Nonetheless I think most of the users use the HTML doc, so it should be
an improvement for them :)
+$(document).ready(function() {
+/* Add a [] button on the top-right corner of code samples to hide
+ * the and ... prompts and the output and thus make the code
+ * copyable. */
I think it would be more user-friendly if the button/trigger would use
real English text like “Hide prompts”/“Show prompts” rather than symbols.
I thought about that and ended up adding a title= with a more accurate
description, while leaving the button short and unobtrusive. A bigger
button might interfer/overlap with the code if the code contains long
lines and/or if the window is too narrow. I expect that people will
anyway try it out as soon as they notice it and learn quickly what it does.
In a couple of years this whole script could be replaced with a couple
of lines of CSS using the CSS3 user-select property (so that only the
code and not the rest is actually copied), but at the moment the support
for it is still a bit lacking and inconsistent.
Best Regards,
Ezio Melotti
Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): test_protocol_sslv2(): Skip this test if ssl.PROTOCOL_SSLv2 is not
On Mon, 31 Oct 2011 19:09:01 +0100
barry.warsaw python-check...@python.org wrote:
http://hg.python.org/cpython/rev/1de4d92cd6a4
changeset: 73258:1de4d92cd6a4
branch: 2.7
parent: 73253:7ce3b719306e
user:Barry Warsaw ba...@python.org
date:Mon Oct 31 14:08:15 2011 -0400
summary:
test_protocol_sslv2(): Skip this test if ssl.PROTOCOL_SSLv2 is not
defined (as is the case with Ubuntu 11.10).
files:
Lib/test/test_ssl.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Lib/test/test_ssl.py b/Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -981,6 +981,8 @@
@skip_if_broken_ubuntu_ssl
def test_protocol_sslv2(self):
Connecting to an SSLv2 server with various client options
+if not hasattr(ssl, 'PROTOCOL_SSLv2'):
+raise unittest.SkipTest('No SSLv2 available')
if test_support.verbose:
sys.stdout.write(\n)
if not hasattr(ssl, 'PROTOCOL_SSLv2'):
I'm not sure, but I've think you've just committed a no-op.
(see http://hg.python.org/cpython/rev/5a080ebd311c)
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
In article CACac1F_V6_6+uG9qfqBJtuokz0HXO53hsXX3Ptap=o8+pxt...@mail.gmail.com, Paul Moore p.f.mo...@gmail.com wrote: On 30 October 2011 18:04, Ned Deily n...@acm.org wrote: Has anyone analyzed the current packages on PyPI to see how many provide binary distributions and in what format? A very quick and dirty check: dmg: 5 rpm: 12 msi: 23 dumb: 132 wininst: 364 egg: 2570 That's number of packages with binary distributions in that format. It's hard to be sure about egg distributions, as many of these could be pure-python (there's no way I know, from the PyPI metadata, to check this). Thanks. If you have access to the egg file name, you should be able to tell. AFAIK, eggs with extension modules include the Distutils platform name in the file name preceded by a '-', so '-linux', '-win32', '-macosx' for the main ones. Pure python eggs do not contain a platform name. http://pypi.python.org/pypi/pyinterval/ is a random example of the former. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging and binary distributions
On 31 October 2011 18:36, Ned Deily n...@acm.org wrote: In article CACac1F_V6_6+uG9qfqBJtuokz0HXO53hsXX3Ptap=o8+pxt...@mail.gmail.com, Paul Moore p.f.mo...@gmail.com wrote: On 30 October 2011 18:04, Ned Deily n...@acm.org wrote: Has anyone analyzed the current packages on PyPI to see how many provide binary distributions and in what format? A very quick and dirty check: dmg: 5 rpm: 12 msi: 23 dumb: 132 wininst: 364 egg: 2570 That's number of packages with binary distributions in that format. It's hard to be sure about egg distributions, as many of these could be pure-python (there's no way I know, from the PyPI metadata, to check this). Thanks. If you have access to the egg file name, you should be able to tell. AFAIK, eggs with extension modules include the Distutils platform name in the file name preceded by a '-', so '-linux', '-win32', '-macosx' for the main ones. Pure python eggs do not contain a platform name. http://pypi.python.org/pypi/pyinterval/ is a random example of the former. 136 architecture-specific 2502 architecture independent About 5%. The numbers don't quite add up, so there's some funnies in there (possibly bad data that I'm not handling well) but it gives an idea. Counts by architecture: win3270 linux-i686 43 win-amd6433 linux-x86_64 26 macosx-10.3-fat 12 macosx-10.5-i386 11 macosx-10.6-universal9 macosx-10.6-fat 8 macosx-10.3-i386 7 macosx-10.6-i386 6 macosx-10.7-intel4 macosx-10.6-intel3 macosx-10.6-x86_64 2 macosx-10.3-ppc 2 macosx-10.4-i386 2 macosx-10.4-ppc 2 py2.3-linux-i686 1 py2.4-linux-i686 1 gnu-0.3-i686-AT386 1 linux-ppc1 cygwin-1.5.25-i686 1 py2.31 py2.41 py2.51 macosx-10.7-x86_64 1 macosx-10.4-universal1 py2.5-linux-i686 1 Most of the 1-counts are bad data in some form. I'm not sure what this proves, to be honest, but what I take from it is: - Nearly all binary distributions are for Windows - Architecture-neutral eggs are common (but not relevant here as packaging can install from source with these) - Ignoring architecture-neutral eggs, most popular formats are wininst, egg, dumb(!!!) and msi - Even the most popular binary format (wininst) only accounts for 2% of all packages. Having said all of this, there are two major caveats I'd include: - Not everything is on PyPI. - This analysis ignores relative importance. It's hard to claim that numpy is no more significant than, say, Products.CMFDynamicViewFTI (whatever that might be - I picked it at random, so apologies to the author :-)) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2011 10:28 AM, Paul Moore wrote: On 31 October 2011 16:08, Tres Seaver tsea...@palladion.com wrote: On 10/31/2011 11:50 AM, Carl Meyer wrote: I have no problem including the basic posix/nt activate scripts if no one else is concerned about the added maintenance burden there. I'm not sure that my cross-shell-scripting fu is sufficient to write posix/activate in a cross-shell-compatible way; I use bash and am not very familiar with other shells. If it runs under /bin/sh is that sufficient to make it compatible with all Unix shells (for some definition of all)? If so, I can work on this. I would say this is a perfect opportunity to delegate, in this case to the devotees of other cults^Wshells than bash. Good call - we'll stick with what we've got until such devotees show up :-) Hey devotees, if you're listening, this is what you want to test/port: https://bitbucket.org/vinay.sajip/pythonv/src/6d057cfaaf53/Lib/venv/scripts/posix/activate For reference, here's what virtualenv ships with (includes a .fish and .csh script): https://github.com/pypa/virtualenv/tree/develop/virtualenv_support For Windows, can you point me at the nt scripts? If they aren't too complex, I'd be willing to port to Powershell. Thanks! They are here: https://bitbucket.org/vinay.sajip/pythonv/src/6d057cfaaf53/Lib/venv/scripts/nt Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6vAKMACgkQ8W4rlRKtE2eEfwCgtpzQtUktUSU8ZyDDeqjD0yEe QXgAoLoCD8EQ74jHR1lWPFjgnwQFkM46 =6+Rn -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code cleanups in stable branches?
Removing dead code and bypassing redundant code are both reasonable bug fixes. The kind of change to be avoided is gratuitous replacement of older idioms with newer ones. -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Code cleanups in stable branches?
On Mon, Oct 31, 2011 at 13:24, Nick Coghlan ncogh...@gmail.com wrote: Removing dead code and bypassing redundant code are both reasonable bug fixes. The kind of change to be avoided is gratuitous replacement of older idioms with newer ones. What Nick said as I was in the middle of typing when he sent this. =) -Brett -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft PEP: virtual environments
Carl Meyer writes: On 31 October 2011 16:08, Tres Seaver tsea...@palladion.com wrote: I would say this is a perfect opportunity to delegate, in this case to the devotees of other cults^Wshells than bash. Good call - we'll stick with what we've got until such devotees show up :-) That's fine, but either make sure it works with a POSIX-conformant /bin/sh, or make the shebang explicitly bash (bash is notoriously buggy in respect of being POSIX-compatible when named sh). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
