[Distutils] setuptools and scripts on Windows
Hi folks, IIIC, there has been a recent change in the setuptools executable that is distributed with the Windows installer (and source). This executable is used as a stub to launch scripts that have been installed using distutils scripts system -- i.e put into C:\Python27\Scripts, or similar) The problem is that the new one launches the scripts in a separate terminal window (DOS box), which then quits when the script is finished, either due to an error or normally. The result is that you can'st see the output of the scripts, which makes any command line script pretty much useless. This means that things like nosetests, etc is broken. Anyway, after much gnashing of teeth, I noticed that if I install the lastest distutils, I get ann easy_install.exe that is about 65kb in size, while an older version had a 7kb exe. If I drop the older on into the scripts dir -- it works fine (tested on 32 bit Windows XP and 64 bit Windows 7 (with 32 bit pyhton). In fact, future easy-installed (or other setuptools installations) scrips then work correctly as well -- it appears that setuptools copies the easy_install.exe (and renames it) to launch the other scripts. Anyway, after poking around a bit, it's not clear to me who is maintaining setuptools, whether this change was intentional, or the result of other needed changes, etc. I can't find a version controlled source where I can look for changes. But I'd really like to see it put back the way it was! This list appeared to be the appropriate place to discuss setuptools, but where do I go from here? -- i.e. where to file a bug report, etc. Thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Fwd: Adding a Pure Python flag to PyPI
[Resending because I don't think the first try made it to the list...] I'm trying to identify which distributions in PyPI need to be made available in binary format for people without C compilers (i.e., distributions including C extensions). I could use the classifier information, but as that is user-supplied, it is not 100% reliable[1]. (Also, it's not in the data set I have available, although that's a fixable issue). I'm only interested in existing binary distributions (eggs and wininst/msi packages) on PyPI. The problem is that simply assuming that because a distribution provides binary installers, or even version-specific installers, is not enough. For example, look at PyParsing - it provides a version-specific wininst installer for every Python version, but it's a pure Python package, and can easily be installed from source. I can't see a way of reliably establishing whether a distribution is pure Python, and yet distutils/packaging clearly has that information available when building. Would it be worthwhile adding a pure Python flag to the PyPI classifiers, which could be automatically populated by packaging? We'd still be reliant on people who manually maintain metadata getting it correct, but it would help in many cases (and in particular, in those cases where projects do regularly upload binary distributions). Alternatively, if there is a way of reliably identifying those packages that can't be installed from source by someone without a compiler, I'd be interested to know. Thanks, Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: Adding a Pure Python flag to PyPI
On 5 March 2012 18:43, Paul Moore p.f.mo...@gmail.com wrote: [Resending because I don't think the first try made it to the list...] I'm trying to identify which distributions in PyPI need to be made available in binary format for people without C compilers (i.e., distributions including C extensions). I could use the classifier information, but as that is user-supplied, it is not 100% reliable[1]. (Also, it's not in the data set I have available, although that's a fixable issue). I'm only interested in existing binary distributions (eggs and wininst/msi packages) on PyPI. The problem is that simply assuming that because a distribution provides binary installers, or even version-specific installers, is not enough. For example, look at PyParsing - it provides a version-specific wininst installer for every Python version, but it's a pure Python package, and can easily be installed from source. I can't see a way of reliably establishing whether a distribution is pure Python, and yet distutils/packaging clearly has that information available when building. Would it be worthwhile adding a pure Python flag to the PyPI classifiers, which could be automatically populated by packaging? We'd still be reliant on people who manually maintain metadata getting it correct, but it would help in many cases (and in particular, in those cases where projects do regularly upload binary distributions). +1 It's useful information for users - if only source distributions are available for packages that require compilation some users can't use them (typically Windows users), so a pure-python flag would be helpful. Michael Alternatively, if there is a way of reliably identifying those packages that can't be installed from source by someone without a compiler, I'd be interested to know. Thanks, Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: Adding a Pure Python flag to PyPI
I can't see a way of reliably establishing whether a distribution is pure Python, and yet distutils/packaging clearly has that information available when building. Would it be worthwhile adding a pure Python flag to the PyPI classifiers, which could be automatically populated by packaging? We'd still be reliant on people who manually maintain metadata getting it correct, but it would help in many cases (and in particular, in those cases where projects do regularly upload binary distributions). I don't think it's worthwhile. It would take forever (literally decades) for this to get into wide use, unless some tool enforces it (e.g. PyPI refuses the upload if there is a C file in the source tarball, yet the package is not marked pure C). Alternatively, if there is a way of reliably identifying those packages that can't be installed from source by someone without a compiler, I'd be interested to know. Depends on how reliable you want it. Whatever mechanism someone can propose, I can find a way to cheat that mechanism. However, downloading the source distribution and inspecting it should be fairly reliable. Regards, Martin ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: Adding a Pure Python flag to PyPI
On Mon, Mar 5, 2012 at 4:21 PM, Martin v. Löwis mar...@v.loewis.de wrote: I can't see a way of reliably establishing whether a distribution is pure Python, and yet distutils/packaging clearly has that information available when building. Would it be worthwhile adding a pure Python flag to the PyPI classifiers, which could be automatically populated by packaging? We'd still be reliant on people who manually maintain metadata getting it correct, but it would help in many cases (and in particular, in those cases where projects do regularly upload binary distributions). I don't think it's worthwhile. It would take forever (literally decades) for this to get into wide use, unless some tool enforces it (e.g. PyPI refuses the upload if there is a C file in the source tarball, yet the package is not marked pure C). distutils/2/packaging should be able to set this automatically. If we do this, maybe the possible values should be yes, no, and don't know. Alternatively, if there is a way of reliably identifying those packages that can't be installed from source by someone without a compiler, I'd be interested to know. Depends on how reliable you want it. Whatever mechanism someone can propose, I can find a way to cheat that mechanism. I don't think anyone has a motive to cheat, unless their goal if to be branded a cheater. :) After all, as you point out, if they cheat, they'll be found out pretty quickly. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Spec for the egg-info format
Is there a good spec of the egg-info (directory) format anywhere? I've found various bits, notably in the setuptools documentation, but I'm trying to get the details clear: - What files are mandatory? - What format should files be in (specifically, line-ending format and to an extent encoding) - Should filenames in installed-files.txt be absolute or relative (and if relative, then to what)? - Directory name format is PACKAGE-VERSION-PYVERSION.egg-info, correct? Always? What about platform-specific binaries? Do they need a platform ID in there? Also, what is the defined filename format for egg files and wininst executables? Is that defined anywhere (it seems to be more or less PACKAGE-VERSION-PYVERSION[-PLATFORM].egg for eggs, and PACKAGE-VERSION[.PLATFORM][-PYVERSION].exe for wininst). If necessary, I can read the code from distutils/setuptools, but there seem to be odd variations on the cheeseshop, and I'd rather be sure what's accepted than stick purely to what the tools generate. But if what the tools generate is all that's going to be reliably accepted, then great, I'll go with that. My main interest is in what pip accepts, FWIW. (I'm trying to write a pip-compatible binary file installer). Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: Adding a Pure Python flag to PyPI
I'm +1 for this, and for packaging to do it automatically. On Monday, March 5, 2012 at 4:43 PM, Jim Fulton wrote: On Mon, Mar 5, 2012 at 4:21 PM, Martin v. Löwis mar...@v.loewis.de (mailto:mar...@v.loewis.de) wrote: I can't see a way of reliably establishing whether a distribution is pure Python, and yet distutils/packaging clearly has that information available when building. Would it be worthwhile adding a pure Python flag to the PyPI classifiers, which could be automatically populated by packaging? We'd still be reliant on people who manually maintain metadata getting it correct, but it would help in many cases (and in particular, in those cases where projects do regularly upload binary distributions). I don't think it's worthwhile. It would take forever (literally decades) for this to get into wide use, unless some tool enforces it (e.g. PyPI refuses the upload if there is a C file in the source tarball, yet the package is not marked pure C). distutils/2/packaging should be able to set this automatically. If we do this, maybe the possible values should be yes, no, and don't know. Alternatively, if there is a way of reliably identifying those packages that can't be installed from source by someone without a compiler, I'd be interested to know. Depends on how reliable you want it. Whatever mechanism someone can propose, I can find a way to cheat that mechanism. I don't think anyone has a motive to cheat, unless their goal if to be branded a cheater. :) After all, as you point out, if they cheat, they'll be found out pretty quickly. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org (mailto:Distutils-SIG@python.org) http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: Adding a Pure Python flag to PyPI
On Mon, Mar 5, 2012 at 10:21 PM, Martin v. Löwis mar...@v.loewis.de wrote: However, downloading the source distribution and inspecting it should be fairly reliable. Depends on what you want to find out. I know a bunch of packages which contain optional C extensions. These certainly aren't pure-python and contain C files in their source distributions. But during setup.py install they'll catch any compilation errors and skip the extension build step. So they are perfectly usable without a C compiler. Or they employ even more logic in their setup.py files and make the C extension conditional on the current platform - like disabling them in PyPy or Jython. Just two examples are zope.interface and Jinja2, which has an entirely optional C extension via setuptools feature support. I guess all I'm asking for is a better name that makes the intent clearer. Hanno ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
