From bruno.braga at gmail.com Fri Mar 2 05:02:07 2012 From: bruno.braga at gmail.com (BRAGA, Bruno) Date: Fri, 2 Mar 2012 14:02:07 +1000 Subject: [Distutils] setup.py, data_files and i18n Message-ID: Hi, I am working on a project written in Python, and I would like to use i18n functionality, but I am having some issues with it, more specifically regarding the .mo files location, and I was hoping someone here could point me in the right direction. (1) i18n mo files location Basically, I already know how to translate contents with gettext, but I got stuck with the fact that it, by default, looks at /usr/share/locale/{language} (in Linux), but the setup.py install data_files into /usr/local/share/... unless I forcibly use absolute paths toward the location where the files should be. (2) install_data.data_files Also, I am having a problem to install the data_files, because the install_data command is never called. I made it work before, but I don't understand what I am missing that worked before and not now. Here is the setup.py script: https://github.com/brunobraga/termsaver/blob/master/setup.py And this is the i18n module I am using as base for localizing all text in the application: https://github.com/brunobraga/termsaver/blob/master/termsaverlib/i18n.py Here is the output of a clean install: bruno at development3;~$ sudo python setup.py install --record /tmp/termsaver.install.record.txt [sudo] password for bruno: running install running build running build_py creating build creating build/lib.linux-i686-2.7 creating build/lib.linux-i686-2.7/termsaverlib copying termsaverlib/constants.py -> build/lib.linux-i686-2.7/termsaverlib copying termsaverlib/i18n.py -> build/lib.linux-i686-2.7/termsaverlib copying termsaverlib/common.py -> build/lib.linux-i686-2.7/termsaverlib copying termsaverlib/exception.py -> build/lib.linux-i686-2.7/termsaverlib copying termsaverlib/__init__.py -> build/lib.linux-i686-2.7/termsaverlib creating build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/programmer.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/rssfeed.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/rfc.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/urlfetcher.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/jokes4all.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/dot.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/__init__.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/asciiartfarts.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/quotes4all.py -> build/lib.linux-i686-2.7/termsaverlib/screen copying termsaverlib/screen/randtxt.py -> build/lib.linux-i686-2.7/termsaverlib/screen creating build/lib.linux-i686-2.7/termsaverlib/screen/base copying termsaverlib/screen/base/rssfeed.py -> build/lib.linux-i686-2.7/termsaverlib/screen/base copying termsaverlib/screen/base/urlfetcher.py -> build/lib.linux-i686-2.7/termsaverlib/screen/base copying termsaverlib/screen/base/filereader.py -> build/lib.linux-i686-2.7/termsaverlib/screen/base copying termsaverlib/screen/base/__init__.py -> build/lib.linux-i686-2.7/termsaverlib/screen/base creating build/lib.linux-i686-2.7/termsaverlib/screen/helper copying termsaverlib/screen/helper/position.py -> build/lib.linux-i686-2.7/termsaverlib/screen/helper copying termsaverlib/screen/helper/urlfetcher.py -> build/lib.linux-i686-2.7/termsaverlib/screen/helper copying termsaverlib/screen/helper/typing.py -> build/lib.linux-i686-2.7/termsaverlib/screen/helper copying termsaverlib/screen/helper/xmlreader.py -> build/lib.linux-i686-2.7/termsaverlib/screen/helper copying termsaverlib/screen/helper/__init__.py -> build/lib.linux-i686-2.7/termsaverlib/screen/helper running build_scripts creating build/scripts-2.7 copying and adjusting termsaver -> build/scripts-2.7 changing mode of build/scripts-2.7/termsaver from 644 to 755 *running build_trans* *Compiling locale/ja.po* *Compiling locale/en.po* running install_lib creating /usr/local/lib/python2.7/dist-packages/termsaverlib copying build/lib.linux-i686-2.7/termsaverlib/constants.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib creating /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/programmer.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/rssfeed.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/rfc.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/urlfetcher.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/jokes4all.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/dot.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen creating /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base copying build/lib.linux-i686-2.7/termsaverlib/screen/base/rssfeed.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base copying build/lib.linux-i686-2.7/termsaverlib/screen/base/urlfetcher.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base copying build/lib.linux-i686-2.7/termsaverlib/screen/base/filereader.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base copying build/lib.linux-i686-2.7/termsaverlib/screen/base/__init__.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base copying build/lib.linux-i686-2.7/termsaverlib/screen/__init__.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/asciiartfarts.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen creating /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/position.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/urlfetcher.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/typing.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/xmlreader.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/__init__.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper copying build/lib.linux-i686-2.7/termsaverlib/screen/quotes4all.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/screen/randtxt.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib/screen copying build/lib.linux-i686-2.7/termsaverlib/i18n.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib copying build/lib.linux-i686-2.7/termsaverlib/common.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib copying build/lib.linux-i686-2.7/termsaverlib/exception.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib copying build/lib.linux-i686-2.7/termsaverlib/__init__.py -> /usr/local/lib/python2.7/dist-packages/termsaverlib byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/constants.py to constants.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/programmer.py to programmer.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/rssfeed.py to rssfeed.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/rfc.py to rfc.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/urlfetcher.py to urlfetcher.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/jokes4all.py to jokes4all.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/dot.py to dot.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/rssfeed.py to rssfeed.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/urlfetcher.py to urlfetcher.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/filereader.py to filereader.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/__init__.py to __init__.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/__init__.py to __init__.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/asciiartfarts.py to asciiartfarts.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/position.py to position.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/urlfetcher.py to urlfetcher.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/typing.py to typing.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/xmlreader.py to xmlreader.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/__init__.py to __init__.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/quotes4all.py to quotes4all.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/randtxt.py to randtxt.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/i18n.py to i18n.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/common.py to common.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/exception.py to exception.pyc byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/__init__.py to __init__.pyc running install_scripts copying build/scripts-2.7/termsaver -> /usr/local/bin changing mode of /usr/local/bin/termsaver to 755 running install_egg_info Writing /usr/local/lib/python2.7/dist-packages/termsaver-0.1_beta.egg-info writing list of installed files to '/tmp/termsaver.install.record.txt' Thank you for trying termsaver. bruno at development3;~$ Any help is much appreciated. I found very hard to do anything with distutils unless I open the source and see by myself what it can do or not... I was hoping there is a better way. Thank you in advance, -- *Braga, Bruno* www.brunobraga.net bruno.braga at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Mon Mar 5 18:13:49 2012 From: chris.barker at noaa.gov (Chris Barker) Date: Mon, 5 Mar 2012 09:13:49 -0800 Subject: [Distutils] setuptools and scripts on Windows Message-ID: 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/OR&R ? ? ? ? ? ?(206) 526-6959?? voice 7600 Sand Point Way NE ??(206) 526-6329?? fax Seattle, WA ?98115 ? ? ??(206) 526-6317?? main reception Chris.Barker at noaa.gov From p.f.moore at gmail.com Mon Mar 5 19:43:54 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 5 Mar 2012 18:43:54 +0000 Subject: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI In-Reply-To: References: Message-ID: [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. From fuzzyman at gmail.com Mon Mar 5 20:21:39 2012 From: fuzzyman at gmail.com (Michael Foord) Date: Mon, 5 Mar 2012 19:21:39 +0000 Subject: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI In-Reply-To: References: Message-ID: On 5 March 2012 18:43, Paul Moore 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Mon Mar 5 22:21:32 2012 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 05 Mar 2012 22:21:32 +0100 Subject: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI In-Reply-To: References: Message-ID: <4F552E5C.6060406@v.loewis.de> > 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 From jim at zope.com Mon Mar 5 22:43:39 2012 From: jim at zope.com (Jim Fulton) Date: Mon, 5 Mar 2012 16:43:39 -0500 Subject: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI In-Reply-To: <4F552E5C.6060406@v.loewis.de> References: <4F552E5C.6060406@v.loewis.de> Message-ID: On Mon, Mar 5, 2012 at 4:21 PM, "Martin v. L?wis" 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 From p.f.moore at gmail.com Mon Mar 5 22:47:36 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 5 Mar 2012 21:47:36 +0000 Subject: [Distutils] Spec for the egg-info format Message-ID: 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. From donald.stufft at gmail.com Mon Mar 5 22:58:01 2012 From: donald.stufft at gmail.com (Donald Stufft) Date: Mon, 5 Mar 2012 16:58:01 -0500 Subject: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI In-Reply-To: References: <4F552E5C.6060406@v.loewis.de> Message-ID: 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" 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 at python.org (mailto:Distutils-SIG at python.org) > http://mail.python.org/mailman/listinfo/distutils-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanno at hannosch.eu Mon Mar 5 23:59:45 2012 From: hanno at hannosch.eu (Hanno Schlichting) Date: Mon, 5 Mar 2012 23:59:45 +0100 Subject: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI In-Reply-To: <4F552E5C.6060406@v.loewis.de> References: <4F552E5C.6060406@v.loewis.de> Message-ID: On Mon, Mar 5, 2012 at 10:21 PM, "Martin v. L?wis" 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 From p.f.moore at gmail.com Mon Mar 5 12:06:19 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 5 Mar 2012 11:06:19 +0000 Subject: [Distutils] Adding a "Pure Python" flag to PyPI Message-ID: 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. From van.lindberg at gmail.com Tue Mar 6 15:09:47 2012 From: van.lindberg at gmail.com (VanL) Date: Tue, 06 Mar 2012 08:09:47 -0600 Subject: [Distutils] Changing sysconfig.cfg values for windows Message-ID: There is a long-standing distinction between Windows,OS2, and every other install scheme - the anomalous placement of binaries in "Scripts." This is being maintained even as we move to packaging/distutils2 - the old values are maintained in _backbport/sysconfig.cfg. For 3.3 would it be possible to regularize the install layouts as much as possible? At least using (lower case) 'bin', 'lib', and 'include' everywhere would go a long way toward easing cross-platform development. Thanks, Van ____________________________ Van Lindberg van.lindberg at gmail.com 972.739.8638 From pje at telecommunity.com Thu Mar 8 06:07:17 2012 From: pje at telecommunity.com (PJ Eby) Date: Thu, 8 Mar 2012 00:07:17 -0500 Subject: [Distutils] Spec for the egg-info format In-Reply-To: References: Message-ID: On Mon, Mar 5, 2012 at 4:47 PM, Paul Moore wrote: > Is there a good spec of the egg-info (directory) format anywhere? The official spec is http://peak.telecommunity.com/DevCenter/EggFormats - What files are mandatory? > PKG-INFO - that's it. The rest are optional - see http://peak.telecommunity.com/DevCenter/EggFormats#standard-metadata > - What format should files be in (specifically, line-ending format and > to an extent encoding) > Setuptools doesn't define an encoding, and it treats any line ending character(s) as line ending characters in the files it reads. Think universal newlines. > - Should filenames in installed-files.txt be absolute or relative (and > if relative, then to what)? > That's defined by the appropriate PEP; setuptools doesn't yet support an installed-files log. > - Directory name format is PACKAGE-VERSION-PYVERSION.egg-info, > correct? Always? The minimum is PACKAGE.egg-info, which is used for "setup.py develop" installs/usage. > What about platform-specific binaries? Do they need a > platform ID in there? > That goes in the .egg filename, yes. See: http://peak.telecommunity.com/DevCenter/EggFormats#filename-embedded-metadata > 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). > The wininst format is distutils defined rather than setuptools-defined; for the rest, see the above link. 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 at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis.ridder at gmail.com Thu Mar 8 19:45:05 2012 From: francis.ridder at gmail.com (Francis Ridder) Date: Thu, 8 Mar 2012 10:45:05 -0800 Subject: [Distutils] A possible example for easier packaging Message-ID: So I just listened to the deployment roundtable and realized that there is another example out there for a "push button" deployment strategy. The PC-BSD project has developed a format to create instalable files that install into isolated directories. It utilizes, during the package build phase, the underlying packaging system to build the pbi. There are a bunch of other cool details but it "could" provide some ways forward to tackle this. Some links to info below. FYI- it is written in shell I believe: http://wiki.pcbsd.org/index.php/PBI9_Format http://wiki.pcbsd.org/index.php/PBI_Manager From merwok at netwok.org Tue Mar 13 17:40:30 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Tue, 13 Mar 2012 17:40:30 +0100 Subject: [Distutils] [RELEASED] Distutils2 1.0a4 In-Reply-To: <4F5F77CB.1040600@netwok.org> References: <4F5F77CB.1040600@netwok.org> Message-ID: <4F5F787E.1090307@netwok.org> What would be a release email without errors? :) The wiki link I gave doesn?t work, it should be http://wiki.python.org/moin/Distutils2/Contributing From merwok at netwok.org Tue Mar 13 17:37:31 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Tue, 13 Mar 2012 17:37:31 +0100 Subject: [Distutils] [RELEASED] Distutils2 1.0a4 Message-ID: <4F5F77CB.1040600@netwok.org> Hello, On behalf of the distutils2 contributors, I am thrilled to announce the release of Distutils2 1.0a4. Distutils2 is the packaging library that supersedes Distutils. It supports distributing, uploading, downloading, installing and removing projects, and is also a support library for other packaging tools like pip and buildout. It will be provided as part of Python 3.3; this release is a backport compatible with Python 2.5 to 2.7. Distutils2 1.0a4 contains a number of known bugs, limitations and missing features, but we have released it to let users and developers download and try it. This means you! If you want to report new issues, request features or contribute, please read DEVNOTES.txt in the source distribution or http://wiki.python.org/Distutils2/Contributing More alpha releases will be cut when important bugs get fixed during the next few months, like Windows or PyPy compatibility. The first beta is planned for June, and 1.0 final for August (to follow Python 3.3.0). Until beta, the API is subject to drastic changes and code can get removed. Basic documentation is at http://docs.python.org/dev/packaging ; it will get updated, expanded and improved in the coming months. Enjoy! Repository: http://hg.python.org/distutils2 Bug tracker: http://bugs.python.org/ (component "Distutils2") Mailing list: http://mail.python.org/mailman/listinfo/distutils-sig/ From encolpe.degoute at free.fr Tue Mar 13 21:19:51 2012 From: encolpe.degoute at free.fr (Encolpe Degoute) Date: Tue, 13 Mar 2012 21:19:51 +0100 Subject: [Distutils] Where are published zc.buildout tests ? Message-ID: Hello, I'm trying to finish a patch for zc.buildout. To prevent any errors I want to compare my tests results with the standard tests. Is there a place where zc.buildout tests are runned and published ? Regards, -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activit?s c?r?brales From benji at benjiyork.com Tue Mar 13 21:35:32 2012 From: benji at benjiyork.com (Benji York) Date: Tue, 13 Mar 2012 16:35:32 -0400 Subject: [Distutils] Where are published zc.buildout tests ? In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 4:19 PM, Encolpe Degoute wrote: > I'm trying to finish a patch for zc.buildout. To prevent any errors I > want to compare my tests results with the standard tests. > Is there a place where zc.buildout tests are runned and published ? See the DEVELOPERS.txt file for instructions on how to set up the test environment. -- Benji York From encolpe.degoute at free.fr Tue Mar 13 23:34:47 2012 From: encolpe.degoute at free.fr (Encolpe Degoute) Date: Tue, 13 Mar 2012 23:34:47 +0100 Subject: [Distutils] Where are published zc.buildout tests ? In-Reply-To: References: Message-ID: <4F5FCB87.4080909@free.fr> Le 13/03/2012 21:35, Benji York a ?crit : > On Tue, Mar 13, 2012 at 4:19 PM, Encolpe Degoute > wrote: >> I'm trying to finish a patch for zc.buildout. To prevent any errors I >> want to compare my tests results with the standard tests. >> Is there a place where zc.buildout tests are runned and published ? > See the DEVELOPERS.txt file for instructions on how to set up the test > environment. I followed again this text and I get this result : Ran 92 tests with 23 failures and 2 errors in 8 minutes 57.157 seconds. That's why I asked for a place where these tests are runned on a daily/commit base to have a comparison. Regards, -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activit?s c?r?brales From dglick at gmail.com Tue Mar 13 23:58:00 2012 From: dglick at gmail.com (David Glick) Date: Tue, 13 Mar 2012 15:58:00 -0700 Subject: [Distutils] Where are published zc.buildout tests ? In-Reply-To: <4F5FCB87.4080909@free.fr> References: <4F5FCB87.4080909@free.fr> Message-ID: On Mar 13, 2012, at 3:34 PM, Encolpe Degoute wrote: > Le 13/03/2012 21:35, Benji York a ?crit : >> On Tue, Mar 13, 2012 at 4:19 PM, Encolpe Degoute >> wrote: >>> I'm trying to finish a patch for zc.buildout. To prevent any errors I >>> want to compare my tests results with the standard tests. >>> Is there a place where zc.buildout tests are runned and published ? >> See the DEVELOPERS.txt file for instructions on how to set up the test >> environment. > > I followed again this text and I get this result : > Ran 92 tests with 23 failures and 2 errors in 8 minutes 57.157 seconds. > > That's why I asked for a place where these tests are runned on a > daily/commit base to have a comparison. > The tests currently pass if you have your development environment set up correctly. Did you read the notes about needing 2 python interpreters available? David From jim at zope.com Wed Mar 14 01:18:40 2012 From: jim at zope.com (Jim Fulton) Date: Tue, 13 Mar 2012 20:18:40 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging Message-ID: Sometimes, binary distributions are useful. This is especially true for Windows and maybe Macs. (They may also be useful for other platforms in closed environments, where the shortcomings of distutils platform definitions aren't such a problem.) Distutils2/packaging (d2/p :) doesn't support the egg format. The bdist format is problematic because: - bdist names don't include Python versions and can't be reliably parsed to get project versions and platforms. - The presence of bdists alongside of source and egg distributions breaks setuptools based tools, like easy_install, pip and buildout because they are mistaken for source distributions with wacky version numbers. In discussing this at the PyCon packaging sprint, Tarek and i came up with the following options: 1) setuptools eggs - Have to support legacy meta-data format 2) bdist - Need to add python version for: - compatibility info - also provides delimeter between version # and platform - Need to update setuptools/distribute to handle (or ignore) them. 3) New egg-like format "pbd" - Arrange suffix so ignored by setuptools/distribute - new-style meta data - would be a zip file - Essentially, .egg format with new-style meta data and different suffix. Option 3) looks the best to us, so we propose: - Introduce a new binary distribution format with a ".pbd" suffix and an egg-like structure. An example file name: ZODB3-3.10.0b1-py2.6-macosx-10.4-x86_64.pbd - Deprecate bdist format. D2/p will not support generation or installation of bdist distributions. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From nick at njwilson.net Wed Mar 14 01:36:08 2012 From: nick at njwilson.net (Nick Wilson) Date: Tue, 13 Mar 2012 17:36:08 -0700 Subject: [Distutils] Packaging poster from PyCon US 2012 Message-ID: Here is the poster on the future of Python packaging that we presented at the PyCon US 2012 poster session. Feel free to hack it up for your own purposes. https://github.com/njwilson/pycon-2012-packaging-poster Thanks, Nick Wilson, Ryan Baker, Taylor Hand, Taylor Michael From carl at oddbird.net Wed Mar 14 03:50:23 2012 From: carl at oddbird.net (Carl Meyer) Date: Tue, 13 Mar 2012 19:50:23 -0700 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: Message-ID: <4F60076F.1080103@oddbird.net> On 03/13/2012 05:18 PM, Jim Fulton wrote: [snip] > 1) setuptools eggs > > - Have to support legacy meta-data format > > 2) bdist > > - Need to add python version for: > - compatibility info > - also provides delimeter between version # and platform > - Need to update setuptools/distribute to handle (or ignore) them. > > 3) New egg-like format "pbd" > > - Arrange suffix so ignored by setuptools/distribute > - new-style meta data > - would be a zip file > > - Essentially, .egg format with new-style meta data and different > suffix. > > Option 3) looks the best to us, so we propose: > > - Introduce a new binary distribution format with a ".pbd" suffix > and an egg-like structure. > > An example file name: > > ZODB3-3.10.0b1-py2.6-macosx-10.4-x86_64.pbd > > - Deprecate bdist format. > > D2/p will not support generation or installation of bdist > distributions. In terms of distribution format, this sounds great; I think a clean break and new format that existing systems will just naturally ignore is the way to go. Your message doesn't address the on-disk installed format. I hope that the installed format (at least the d2/p default) will be consistent with PEP 376 (unzipped and "flat"), not an egg-style importable zip file relying on its own dedicated entry in a pth file. Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From pje at telecommunity.com Wed Mar 14 04:00:52 2012 From: pje at telecommunity.com (PJ Eby) Date: Tue, 13 Mar 2012 23:00:52 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 8:18 PM, Jim Fulton wrote: > 3) New egg-like format "pbd" > > - Arrange suffix so ignored by setuptools/distribute > - new-style meta data > - would be a zip file > > - Essentially, .egg format with new-style meta data and different > suffix. > FWIW, if I were designing the .egg format today with 20/20 hindsight, I would use 'package-version.egg-info' instead of 'EGG-INFO' as the metadata directory. It would make discovery and converting to flat (pip/legacy-style) installations easier, as you could just unzip to the target directory. Apart from that, I'm not sure what else you'll actually gain by introducing a new format. IIUC, what new-style metadata egg files lack can be determined programmatically from their contents or the existing metadata files, so there seems to be little reason not to at least consume existing egg files. Conversely, egg files support arbitrary metadata -- which means you can include whatever additional new-style data you want... so there seems little reason not to simply add whatever extra metadata you want to them. But perhaps there was some consideration or use case I'm not aware of? -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl at oddbird.net Wed Mar 14 09:34:20 2012 From: carl at oddbird.net (Carl Meyer) Date: Wed, 14 Mar 2012 01:34:20 -0700 Subject: [Distutils] Spec for the egg-info format In-Reply-To: References: Message-ID: <4F60580C.8000604@oddbird.net> On 03/07/2012 09:07 PM, PJ Eby wrote: > On Mon, Mar 5, 2012 at 4:47 PM, Paul Moore > wrote: > > Is there a good spec of the egg-info (directory) format anywhere? [snip] > - Should filenames in installed-files.txt be absolute or relative (and > if relative, then to what)? > > > That's defined by the appropriate PEP; setuptools doesn't yet support an > installed-files log. I have nothing to add except for here; installed-files.txt is not specified in any PEP AFAIK, it's pip-specific (and generated by the distutils install --record option). Generally the filenames in it are relative to the location of installed-files.txt itself; absolute paths will work equally well for uninstall (where the installed-files log is used), but obviously become wrong if the installation were relocated. All the files in .egg-info aside from installed-files.txt are generated by setuptools and not touched by pip. Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nitinkdhiman at gmail.com Wed Mar 14 11:10:55 2012 From: nitinkdhiman at gmail.com (Nitin Dhiman) Date: Wed, 14 Mar 2012 15:40:55 +0530 Subject: [Distutils] easy_install problem Message-ID: Greetings, My OS is Ubuntu Lucid lynx 10.04, with Python disutils python-setuptools version 0.6.10-4ubuntu1 I am behind proxy. http_proxy and https_proxy is defined as http://username:passwd at proxy-ip:port I am trying to use easy_install to install rosinstall using following command: nitin at nitin-desktop:~/Downloads$ sudo easy_install -U rosinstall vcstools [sudo] password for nitin: Searching for rosinstall Reading http://pypi.python.org/simple/rosinstall/ Download error: [Errno -2] Name or service not known -- Some packages may not be found! Reading http://pypi.python.org/simple/rosinstall/ Download error: [Errno -2] Name or service not known -- Some packages may not be found! Couldn't find index page for 'rosinstall' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Download error: [Errno -2] Name or service not known -- Some packages may not be found! No local packages or download links found for rosinstall error: Could not find suitable distribution for Requirement.parse('rosinstall') This repeats couple of times. Is this issue related to proxy??? I do not face any problem when having a direct internet connnection. I had tried using pip also but i gets problems. Following is the output of log file. Downloading/unpacking rosinstall ? Getting page http://pypi.python.org/simple/rosinstall ? Could not fetch URL http://pypi.python.org/simple/rosinstall: ? Will skip URL http://pypi.python.org/simple/rosinstall when looking for download links for rosinstall ? Getting page http://pypi.python.org/simple/ ? Could not fetch URL http://pypi.python.org/simple/: ? Will skip URL http://pypi.python.org/simple/ when looking for download links for rosinstall ? Cannot fetch index base URL http://pypi.python.org/simple/ Cannot find requirement rosinstall, nor fetch index URL http://pypi.python.org/simple/ Exception information: Traceback (most recent call last): ? File "/usr/lib/python2.6/dist-packages/pip.py", line 252, in main ? ? self.run(options, args) ? File "/usr/lib/python2.6/dist-packages/pip.py", line 408, in run ? ? requirement_set.install_files(finder, force_root_egg_info=self.bundle) ? File "/usr/lib/python2.6/dist-packages/pip.py", line 1750, in install_files ? ? url = finder.find_requirement(req_to_install, upgrade=self.upgrade) ? File "/usr/lib/python2.6/dist-packages/pip.py", line 996, in find_requirement ? ? url_name = self._find_url_name(Link(self.index_urls[0]), url_name, req) ? File "/usr/lib/python2.6/dist-packages/pip.py", line 1073, in _find_url_name ? ? raise DistributionNotFound('Cannot find requirement %s, nor fetch index URL %s' % (req, index_url)) DistributionNotFound: Cannot find requirement rosinstall, nor fetch index URL http://pypi.python.org/simple/ The package I am trying to install is from ROS (www.ros.org) . The community of ROS has suggested to ask the solution in this community . I hope some one can solve the problem. Could this problem be because of any proxy rules???? I am not aware of these. regards prince From p.f.moore at gmail.com Wed Mar 14 11:52:45 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 14 Mar 2012 10:52:45 +0000 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <4F60076F.1080103@oddbird.net> References: <4F60076F.1080103@oddbird.net> Message-ID: On 14 March 2012 02:50, Carl Meyer wrote: > In terms of distribution format, this sounds great; I think a clean > break and new format that existing systems will just naturally ignore is > the way to go. Agreed. I created a patch a while ago for a "bdist_simple" format, which has languished in the tracker for a while. It's a very basic patch, and the format is essentially just a stripped down version of the wininst format (a zip file with distinguished placeholder directories at the top level). I'm not sure I understand Jim's issues with the wininst format, so I can't respond as to why this wouldn't address them. I'd started writing a PEP for bdist_simple with ?ric Araujo but stalled because I didn't have time. If someone else takes up the baton with a binary distribution format, that's fine with me. > Your message doesn't address the on-disk installed format. I hope that > the installed format (at least the d2/p default) will be consistent with > PEP 376 (unzipped and "flat"), not an egg-style importable zip file > relying on its own dedicated entry in a pth file. I agree that a flat on-disk format is essential. It's what pip and the standard tools use. The .pth based egg format appears to only have benefits if you want to manage multiple versions, and as far as I can see that requirement is now better satisfied via virtualenv/pip. One other point - it's actually relatively easy to write a tool to introspect egg and wininst format files, and unpack them manually into the on-disk layout needed. I have the bones of such a thing for pip (needs completing before I can release it). I would suggest that for backward compatibility and transition purposes, the following things need to be considered: - There should be converters from egg and wininst formats to the new format. Not everyone will start producing the new format immediately, and we should offer users a migration path where packagers haven't moved over. These should be trivial to write. - There should also be a converter from MSI format, but that's a beast to write and I'd say not worth the effort. - External tools like pip will need to handle the new format, ideally. Or at least keep out of the way when pysetup install is used. I'm assuming that pysetup install works in a virtualenv. Is the intention to promote the new format for older Python versions as well, via distutils2, or will this be a purely Python 3.3 option? If the former, conversion and compatibility is crucial, if the latter, then less so but we need to avoid causing problems for early adopter users who rely on packagers who haven't moved yet ("Lobby the package maintainer to change" is never a helpful answer...) The key here is that the new format needs to be a unifying effort - we already have 3 binary formats, if this new format merely adds a fourth, then in my view it's a failure. It needs to be the "one obvious way" if it's to work. Paul. PS A couple of relevant python-dev threads, for people who haven't seen them: http://mail.python.org/pipermail/python-dev/2011-October/114285.html http://mail.python.org/pipermail/python-dev/2011-October/113956.html http://mail.python.org/pipermail/python-dev/2011-October/114243.html From tarek at ziade.org Wed Mar 14 03:56:38 2012 From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Tue, 13 Mar 2012 19:56:38 -0700 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <4F60076F.1080103@oddbird.net> References: <4F60076F.1080103@oddbird.net> Message-ID: <4F6008E6.7020200@ziade.org> On 3/13/12 7:50 PM, Carl Meyer wrote: > On 03/13/2012 05:18 PM, Jim Fulton wrote: > [snip] >> 1) setuptools eggs >> >> - Have to support legacy meta-data format >> >> 2) bdist >> >> - Need to add python version for: >> - compatibility info >> - also provides delimeter between version # and platform >> - Need to update setuptools/distribute to handle (or ignore) them. >> >> 3) New egg-like format "pbd" >> >> - Arrange suffix so ignored by setuptools/distribute >> - new-style meta data >> - would be a zip file >> >> - Essentially, .egg format with new-style meta data and different >> suffix. >> >> Option 3) looks the best to us, so we propose: >> >> - Introduce a new binary distribution format with a ".pbd" suffix >> and an egg-like structure. >> >> An example file name: >> >> ZODB3-3.10.0b1-py2.6-macosx-10.4-x86_64.pbd >> >> - Deprecate bdist format. >> >> D2/p will not support generation or installation of bdist >> distributions. > In terms of distribution format, this sounds great; I think a clean > break and new format that existing systems will just naturally ignore is > the way to go. > > Your message doesn't address the on-disk installed format. I hope that > the installed format (at least the d2/p default) will be consistent with > PEP 376 (unzipped and "flat"), not an egg-style importable zip file > relying on its own dedicated entry in a pth file. yeah the installation format is PEP 376 for *all* distributions, including the old ones: whatever gets installed is converted into PEP 376 if it's not a distutils2-based project We're only talking here about a replacement for a binary *distribution*. distutils' bdist is broken (the name of the file does not contain the py version...) while setuptools' egg would be a decent choice, it adds more legacy burden. I am excited we had that discussion with Jim, 3) seems the way forward for us. Cheers Tarek > > Carl > > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Wed Mar 14 13:21:16 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 14 Mar 2012 12:21:16 +0000 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <4F6008E6.7020200@ziade.org> References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> Message-ID: On 14 March 2012 02:56, Tarek Ziad? wrote: > distutils' bdist is broken (the name of the file does not contain the py > version...) ?? bdist_wininst filenames contain the python version when it matters (i.e., when there are binaries in the file). One thing I dislike about eggs is that the filename includes a Python version for all eggs, even when the package is pure python. I know eggs contain .pyc files (which are version specific) but IMO they shouldn't. Having a python version in the filename where it's not necessary increases the maintenance burden on packagers, who have to generate the extra files, and for users, who have to work out whether the package actually is version specific, or whether they can just install from source. Please can we have a new format that only has a Python version in the filename if it matters? Paul. From jim at zope.com Wed Mar 14 16:17:10 2012 From: jim at zope.com (Jim Fulton) Date: Wed, 14 Mar 2012 11:17:10 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 11:00 PM, PJ Eby wrote: ... > I'm not sure what else you'll actually gain by introducing > a new format. ?IIUC, what new-style metadata egg files lack can be > determined programmatically from their contents or the existing metadata > files, so there seems to be little reason not to at least consume existing > egg files. I'm not sure whether you're referring to the distribution format, or the meta-data format, or both. I don't really have an opinion, myself, about the meta data format. Other have decided it's going to be different. Having decided to use a different meta data format, it makes sense to use a different distribution format. While d2/p might support eggs for a while (not sure of that), we wouldn't want new distributions to be in egg format, so we need an alternative. (Personally, I don't have an issue with the egg format, but the decision was made by others to move away from it.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From jim at zope.com Wed Mar 14 16:43:35 2012 From: jim at zope.com (Jim Fulton) Date: Wed, 14 Mar 2012 11:43:35 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> Message-ID: On Wed, Mar 14, 2012 at 6:52 AM, Paul Moore wrote: > On 14 March 2012 02:50, Carl Meyer wrote: >> In terms of distribution format, this sounds great; I think a clean >> break and new format that existing systems will just naturally ignore is >> the way to go. > > Agreed. I created a patch a while ago for a "bdist_simple" format, > which has languished in the tracker for a while. It's a very basic > patch, and the format is essentially just a stripped down version of > the wininst format (a zip file with distinguished placeholder > directories at the top level). I'm not sure I understand Jim's issues > with the wininst format, so I can't respond as to why this wouldn't > address them. My main issue is that I think we need a standard binary format that isn't system dependent. I see the wininst format as sort of a two-edged sword for libraries. On the one hand, it makes installing libraries natural for Windows users, on the other, it encourages poor hygiene. ... >> Your message doesn't address the on-disk installed format. I hope that >> the installed format (at least the d2/p default) will be consistent with >> PEP 376 (unzipped and "flat"), not an egg-style importable zip file >> relying on its own dedicated entry in a pth file. > > I agree that a flat on-disk format is essential. It's what pip and the > standard tools use. Um....nevermind. > The .pth based egg format appears to only have > benefits if you want to manage multiple versions, and as far as I can > see that requirement is now better satisfied via virtualenv/pip. I don't see how virtualenv/pip address that. I assume you mean that if 2 applications/scripts require two different versions of a package, they should use two separate virtualenvs. That feels kinda heavy to me, but to each their own. :) FTR, buildout uses eggs to support multiple package versions. It doesn't use .pth files, but bakes necessary paths into generated scripts. Buildout on d2/p will continue creating egg-like structures, both to support multiple versions and to support caching and sharing installed packages. > One other point - it's actually relatively easy to write a tool to > introspect egg and wininst format files, and unpack them manually into > the on-disk layout needed. I have the bones of such a thing for pip > (needs completing before I can release it). > > I would suggest that for backward compatibility and transition > purposes, the following things need to be considered: > > - There should be converters from egg and wininst formats to the new > format. Not everyone will start producing the new format immediately, > and we should offer users a migration path where packagers haven't > moved over. These should be trivial to write. +1 ... > - External tools like pip will need to handle the new format, ideally. > Or at least keep out of the way when pysetup install is used. I'm > assuming that pysetup install works in a virtualenv. My hope is that pip will eventually use d2/p. > Is the intention to promote the new format for older Python versions > as well, via distutils2, Yes > or will this be a purely Python 3.3 option? No. > If the former, conversion and compatibility is crucial, +1 ... > The key here is that the new format needs to be a unifying effort - we > already have 3 binary formats, if this new format merely adds a > fourth, then in my view it's a failure. It needs to be the "one > obvious way" if it's to work. > > Paul. > > PS A couple of relevant python-dev threads, for people who haven't seen them: > > http://mail.python.org/pipermail/python-dev/2011-October/114285.html > http://mail.python.org/pipermail/python-dev/2011-October/113956.html > http://mail.python.org/pipermail/python-dev/2011-October/114243.html Thanks for sharing these. You raise an interesting point in the last link. It's reasonable to argue that this is only a windows problem. It could be argued that, on other platforms: - Consumers of applications should get application installers, possibly with embedded copies of Python. - Consumers of libraries are developers who should be able to install development tools. I find the notion that we only need a binary format for Windows unsatisfying and unsettling, but if everyone else feels that way, I can live with it. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From p.f.moore at gmail.com Wed Mar 14 17:17:26 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 14 Mar 2012 16:17:26 +0000 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> Message-ID: On 14 March 2012 15:43, Jim Fulton wrote: > My main issue is that I think we need a standard binary format that > isn't system dependent. I didn't intend bdist_simple to be platform-specific. It's based on bdist_wininst certainly, but I stripped out all the platform-specific bits (the embedding in the executable). The resulting format is simply a zip file with separate directories for each of the sysconfig target locations. > I see the wininst format as sort of a two-edged sword for libraries. > On the one hand, it makes installing libraries natural for Windows > users, on the other, it encourages poor hygiene. Not sure what you mean by "poor hygiene", but if you mean "installing everything into the system Python" then I agree, and that's why I want something like virtualenv to have support for some binary format (via pip, packaging, or whatever). > You raise an interesting point in the last link. > > It's reasonable to argue that this is only a windows problem. I'm a Windows-only user, so I only have experience of that platform, and it definitely is an issue there. When I stated on python-dev that binary distributions seemed to be only an issue on Windows, a number of Unix users (Nick Coghlan in particular, IIRC) argued that Unix users would also benefit from binary packages. So I tried to design something platform-neutral, although it needs a non-Windows user to take a look and confirm whether or not there are platform dependencies I missed. > It could be argued that, on other platforms: > > - Consumers of applications should get application installers, > ?possibly with embedded copies of Python. >From my experience, that happens more often on Windows than elsewhere (py2exe/cx_Freeze). I didn't think Unix people did that. > - Consumers of libraries are developers who should be able > ?to install development tools. That was Nick's point, that sometimes even on Unix dependencies can be hard to install or complex to build, so there is value in binary distributions in those cases. > I find the notion that we only need a binary format for Windows > unsatisfying and unsettling, but if everyone else feels that way, > I can live with it. So do I - but as you say, I can live with it (as long as "Windows only" doesn't end up translating into "not worth bothering about"...) Paul. From pje at telecommunity.com Wed Mar 14 17:33:31 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 12:33:31 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> Message-ID: On Wed, Mar 14, 2012 at 8:21 AM, Paul Moore wrote: > One thing I dislike about eggs is that the filename includes a Python > version for all eggs, even when the package is pure python. I know > eggs contain .pyc files (which are version specific) but IMO they > shouldn't. Your objection would make sense if .egg files were simply a format for transmitting files to be installed someplace -- in which case they could've omitted the .pyc files. .egg files were originally designed as a plugin distribution format, which means they're supposed to be drop-in usable to an app's plugin directory. Which brings up a few questions, actually. Will these .pbd files be drop-in usable in the same way? If not, then they're not really replacing eggs. The same is true if they don't offer plugin discovery metadata like entry points or EggTranslations. > Having a python version in the filename where it's not > necessary increases the maintenance burden on packagers, who have to > generate the extra files, This is a bit of a misconception, perhaps originating in the fact that setuptools itself was always distributed as a collection of version-specific eggs. This was done solely to ease the bootstrapping of setuptools itself (to avoid recursively invoking the distutils while trying to build another package), and isn't really necessary for easy_install or other tools. You only need to generate eggs if you are supporting a binary application of some kind. Again, this raises the question: is .pbd a load-and-go format for distributing and *running* Python code, or is it just a way to bundle compiled extensions along with source code to simplify installation? I worry that some folks in the conversation may be thinking one thing, and some folks the other. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl at oddbird.net Wed Mar 14 17:38:58 2012 From: carl at oddbird.net (Carl Meyer) Date: Wed, 14 Mar 2012 09:38:58 -0700 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> Message-ID: <4F60C9A2.7060002@oddbird.net> On 03/14/2012 09:33 AM, PJ Eby wrote: > Again, this raises the question: is .pbd a load-and-go format for > distributing and *running* Python code, or is it just a way to bundle > compiled extensions along with source code to simplify installation? I > worry that some folks in the conversation may be thinking one thing, and > some folks the other. I think it was already clarified that it is the latter - purely a distribution format, intended for unzipped PEP-376 style installation, not drop-in use. Which means that no, it isn't a full replacement for eggs (I don't think that was the goal). Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From jim at zope.com Wed Mar 14 17:42:18 2012 From: jim at zope.com (Jim Fulton) Date: Wed, 14 Mar 2012 12:42:18 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <4F60C9A2.7060002@oddbird.net> References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60C9A2.7060002@oddbird.net> Message-ID: On Wed, Mar 14, 2012 at 12:38 PM, Carl Meyer wrote: > > On 03/14/2012 09:33 AM, PJ Eby wrote: >> Again, this raises the question: is .pbd a load-and-go format for >> distributing and *running* Python code, or is it just a way to bundle >> compiled extensions along with source code to simplify installation? ?I >> worry that some folks in the conversation may be thinking one thing, and >> some folks the other. > > I think it was already clarified that it is the latter - purely a > distribution format, intended for unzipped PEP-376 style installation, > not drop-in use. Which means that no, it isn't a full replacement for > eggs (I don't think that was the goal). Right. It is only a replacement for use of eggs as a binary distribution (not installation) format. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From pje at telecommunity.com Wed Mar 14 17:54:40 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 12:54:40 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: Message-ID: On Wed, Mar 14, 2012 at 11:17 AM, Jim Fulton wrote: > On Tue, Mar 13, 2012 at 11:00 PM, PJ Eby wrote: > ... > > I'm not sure what else you'll actually gain by introducing > > a new format. IIUC, what new-style metadata egg files lack can be > > determined programmatically from their contents or the existing metadata > > files, so there seems to be little reason not to at least consume > existing > > egg files. > > I'm not sure whether you're referring to the distribution format, or > the meta-data format, or both. > > I don't really have an opinion, myself, about the meta data format. > Other have decided it's going to be different. > > Having decided to use a different meta data format, it makes sense to > use a different > distribution format. While d2/p might support eggs for a while (not > sure of that), we > wouldn't want new distributions to be in egg format, so we need an > alternative. > > (Personally, I don't have an issue with the egg format, but the decision > was > made by others to move away from it.) > In that case, I think it's really important to explicitly spell out the requirements and use cases for the new format; different people use .egg files differently, and the discussion here already reflects these different perceptions. The packaging PEPs cover only replacements for EGG-INFO/PKG-INFO and EGG-INFO/requires.txt. AFAIK, they don't include replacements for: * entry_points.txt -- plugin discovery * namespace_packages.txt -- namespace package management * dependency_links.txt -- suggesting additional locations for finding dependencies * native_libs.txt, eager_resources.txt, zip-safe/zip-not-safe -- support for in-zipfile access to resources and native libraries Which of these use cases will be supported by the new format, and which will not? Dropping any of them essentially means that some people are not going to have a migration path. (PEP 382 or 402 will eventually clear up the namespace_packages bit, but are unlikely to be backported to 2.x.) Also, is there an official discovery API for finding additional metadata (such as would be needed by EggTranslations' i18n system built on egg metadata)? I assume that you're aware of most of the above, as Zope has historically made use of at least the first two items on the list above. But a PEP for this new format really ought to spell out the use cases it's going to handle, or not, and why (or why not). -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Wed Mar 14 17:58:30 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 12:58:30 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60C9A2.7060002@oddbird.net> Message-ID: On Wed, Mar 14, 2012 at 12:42 PM, Jim Fulton wrote: > Right. It is only a replacement for use of eggs as a binary distribution > (not installation) format. > Or to put it another way, it won't be a replacement for eggs at all. It'll be a replacement for bdist_wininst. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Wed Mar 14 18:06:52 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 13:06:52 -0400 Subject: [Distutils] easy_install problem In-Reply-To: References: Message-ID: Try running your command with '-vv' to increase the verbosity, and with PYDISTUTILS_DEBUG=true in your environment; you may get back more detailed error information that may assist you in finding out what's happening with the proxy. On Wed, Mar 14, 2012 at 6:10 AM, Nitin Dhiman wrote: > Greetings, > My OS is Ubuntu Lucid lynx 10.04, with Python disutils > python-setuptools version 0.6.10-4ubuntu1 > > I am behind proxy. http_proxy and https_proxy is defined as > http://username:passwd at proxy-ip:port > > I am trying to use easy_install to install rosinstall using following > command: > > > nitin at nitin-desktop:~/Downloads$ sudo easy_install -U rosinstall vcstools > [sudo] password for nitin: > Searching for rosinstall > Reading http://pypi.python.org/simple/rosinstall/ > Download error: [Errno -2] Name or service not known -- Some packages > may not be found! > Reading http://pypi.python.org/simple/rosinstall/ > Download error: [Errno -2] Name or service not known -- Some packages > may not be found! > Couldn't find index page for 'rosinstall' (maybe misspelled?) > Scanning index of all packages (this may take a while) > Reading http://pypi.python.org/simple/ > Download error: [Errno -2] Name or service not known -- Some packages > may not be found! > No local packages or download links found for rosinstall > error: Could not find suitable distribution for > Requirement.parse('rosinstall') > > > This repeats couple of times. Is this issue related to proxy??? I do > not face any problem when having a direct internet connnection. > I had tried using pip also but i gets problems. Following is the > output of log file. > > Downloading/unpacking rosinstall > Getting page http://pypi.python.org/simple/rosinstall > Could not fetch URL http://pypi.python.org/simple/rosinstall: > > Will skip URL http://pypi.python.org/simple/rosinstall when looking > for download links for rosinstall > Getting page http://pypi.python.org/simple/ > Could not fetch URL http://pypi.python.org/simple/: [Errno -2] Name or service not known> > Will skip URL http://pypi.python.org/simple/ when looking for > download links for rosinstall > Cannot fetch index base URL http://pypi.python.org/simple/ > Cannot find requirement rosinstall, nor fetch index URL > http://pypi.python.org/simple/ > Exception information: > Traceback (most recent call last): > File "/usr/lib/python2.6/dist-packages/pip.py", line 252, in main > self.run(options, args) > File "/usr/lib/python2.6/dist-packages/pip.py", line 408, in run > requirement_set.install_files(finder, force_root_egg_info=self.bundle) > File "/usr/lib/python2.6/dist-packages/pip.py", line 1750, in > install_files > url = finder.find_requirement(req_to_install, upgrade=self.upgrade) > File "/usr/lib/python2.6/dist-packages/pip.py", line 996, in > find_requirement > url_name = self._find_url_name(Link(self.index_urls[0]), url_name, req) > File "/usr/lib/python2.6/dist-packages/pip.py", line 1073, in > _find_url_name > raise DistributionNotFound('Cannot find requirement %s, nor fetch > index URL %s' % (req, index_url)) > DistributionNotFound: Cannot find requirement rosinstall, nor fetch > index URL http://pypi.python.org/simple/ > > > The package I am trying to install is from ROS (www.ros.org) . The > community of ROS has suggested to ask the solution in this community . > I hope some one can solve the problem. > Could this problem be because of any proxy rules???? I am not aware of > these. > > regards > prince > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Wed Mar 14 18:42:03 2012 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 14 Mar 2012 10:42:03 -0700 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> Message-ID: On Wed, Mar 14, 2012 at 9:17 AM, Paul Moore wrote: >> It's reasonable to argue that this is only a windows problem. no -- it's a Mac OS-X problem, too. Indeed, a harder one, due to: A) The Mac platform now has 4! architectures: PPC, PPC64, x86, intel64. Granted, PPC is almost dead, PPC64 never saw much use, and even 32 bit x86 is on the way out. Never the less -- at least 32 and 64bit intel are going to be around for a while. B) OS-X support fat binaries, and the pyton.org binaries have been built that way for ages. C) OS-X moves forward, fast -- it's gets pretty ticky to build binaries that run on older versions than the one you are building on (it can be done, to a point, but it's hard to get right) >> - Consumers of applications should get application installers, >> ?possibly with embedded copies of Python. sure -- but people developers need to build those... > >From my experience, that happens more often on Windows than elsewhere > (py2exe/cx_Freeze). I didn't think Unix people did that. not as much, but Mac developers do. >> - Consumers of libraries are developers who should be able >> ?to install development tools. In theory, yes, but: 1) there are folks that want to do a little python that don't have any experience or interest in the whole C building thing -- and to get the compiler on the Mac, you need to register with Mac Developer connection, then download a MASSIVE binary -- it's not a trivial lift. 2) as a stated above, building binaries of packages that you can re-distribute to other systems (py2app) is tricky -- even more so when you need compiled dependencies (libjpeg, libfreetype, that sort of thing) So the short version is -- binary packages are important on the Mac. Which brings up another point: Universal binaries (i.e. more than one architecture in one binary) have never been properly supported by binary eggs/setuptools. I think it may be as simple as the naming convention -- the binary would be named according to the machine it was built on (i.e. PPC) but when you tried to install in on another machine, setuptools would look for one called, i.e. "x86" and not find it. There may be some other issues, too, but in any case, we need to make sure the naming convention handles the multi-architecture case as well. -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 Chris.Barker at noaa.gov From p.f.moore at gmail.com Wed Mar 14 18:45:39 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 14 Mar 2012 17:45:39 +0000 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60C9A2.7060002@oddbird.net> Message-ID: On 14 March 2012 16:58, PJ Eby wrote: > On Wed, Mar 14, 2012 at 12:42 PM, Jim Fulton wrote: >> >> Right. ?It is only a replacement for use of eggs as a binary distribution >> (not installation) format. > > > Or to put it another way, it won't be a replacement for eggs at all. ?It'll > be a replacement for bdist_wininst. That is certainly my understanding. Do we need a replacement for eggs? It seems to me that the people who use them (not me) are happy with them as they stand. On the other hand, packaging currently doesn't have *any* equivalent of bdist_wininst (other than to use the legacy version unchanged) - specifically, there's no binary format that pysetup install will use - so there's a reasonably clear need there. Paul. From peterdonner at utah.gov Wed Mar 14 16:21:38 2012 From: peterdonner at utah.gov (Peter Donner) Date: Wed, 14 Mar 2012 09:21:38 -0600 Subject: [Distutils] distribute-0625 install problem References: <4F606129020000FC00025EBF@gvem002sp.state.ut.us> <4F606322020000FC00025EC3@gvem002sp.state.ut.us> Message-ID: <4F606322020000FC00025EC3@gvem002sp.state.ut.us> Before I read the instructions, downloaded the tarball to c:\temp Extracted files to C:\temp\distribute-0.6.25 >From Dos command window in the C:\temp\distribute-0.6.25 directory issued command python setup.py install Got error "no module named distutils.util", but util.py is in C:\Python32\Lib\distutils Frustrating Then I read instructions Downloaded distribute_setup.py to C:\Python32\Lib Ran distribute_setup.py in IDLE, got following message in red, which from my very limited python experience seems to be not good Traceback (most recent call last): File "C:\temp\distribute-0.6.25\distribute_setup.py", line 494, in main(sys.argv[1:]) File "C:\temp\distribute-0.6.25\distribute_setup.py", line 489, in main tarball = download_setuptools() File "C:\temp\distribute-0.6.25\distribute_setup.py", line 192, in download_setuptools log.warn("Downloading %s", url) File "C:\Python32\lib\distutils\log.py", line 47, in warn self._log(WARN, msg, args) File "C:\Python32\lib\distutils\log.py", line 30, in _log if stream.errors == 'strict': AttributeError: errors My ultimate goal is to install beautifulsoup4 to parse webpages. Steps I have been told to follow 1) install python 3.2.2 (with msi installer) 2) install distribute-0.6.24 (with "python setup.py install") 3) install lxml-2.3-py3.2-win32.egg (with "easy_install lxml-2.3- py3.2-win32.egg") 4) install beautifulsoup4-4.0.0b10 (with "easy_install beautifulsoup4") Step 1 is complete. Step 2, can't seem to get 0.6.24, so tried 0.6.25. Seems I have not succeeded, at least don't seem to be able to use easy_install Any help will be greatly appreciated -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Wed Mar 14 20:16:51 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 15:16:51 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60C9A2.7060002@oddbird.net> Message-ID: On Wed, Mar 14, 2012 at 1:45 PM, Paul Moore wrote: > On 14 March 2012 16:58, PJ Eby wrote: > > On Wed, Mar 14, 2012 at 12:42 PM, Jim Fulton wrote: > >> > >> Right. It is only a replacement for use of eggs as a binary > distribution > >> (not installation) format. > > > > > > Or to put it another way, it won't be a replacement for eggs at all. > It'll > > be a replacement for bdist_wininst. > > That is certainly my understanding. Do we need a replacement for eggs? > Nope. My only concern is that unless this is made really clear, people are likely to think this *is* intended to replace eggs, confusing eggs-in-general with eggs-as-improved-bdist_dumb/wininst. Other than that, replacing bdist_dumb and bdist_wininst with something more sane has my +1. (I just want it clearly labeled as such, since all the discussion about possibly using the egg format may confuse the unwary.) If I understand correctly, all this proposal does is update bdist_dumb to use a saner naming convention, standardize on zip format, and flatten the inner directory layout. A sort of "bdist_dumb2", if you will. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pje at telecommunity.com Wed Mar 14 20:22:36 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 15:22:36 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> Message-ID: On Wed, Mar 14, 2012 at 1:42 PM, Chris Barker wrote: > > Universal binaries (i.e. more than one architecture in one binary) > have never been properly supported by binary eggs/setuptools. I think > it may be as simple as the naming convention -- the binary would be > named according to the machine it was built on (i.e. PPC) but when you > tried to install in on another machine, setuptools would look for one > called, i.e. "x86" and not find it. There may be some other issues, > too, but in any case, we need to make sure the naming convention > handles the multi-architecture case as well. > FWIW, all the setuptools platform compatibility code for Mac OS was contributed by Bob Ippolito, and I don't remember his rationale for not supporting fat binaries exactly, although at the time (almost a decade ago) there were only two architectures and things in general were much simpler then. ;-) If you settle on a naming convention that works, patches to the pkg_resources functions 'compatible_platforms()', 'get_build_platform()', and 'get_supported_platform()' are welcome. These are the only parts of setuptools that need to "understand" platform strings as anything other than an opaque identifier. (For that matter, if anybody comes up with a sane platform naming convention for any *other* platforms, patches for those are welcome too!) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zvezdan at computer.org Wed Mar 14 23:05:55 2012 From: zvezdan at computer.org (Zvezdan Petkovic) Date: Wed, 14 Mar 2012 18:05:55 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> Message-ID: <513A7E3F-BFAC-4A19-9892-F05E066DC519@computer.org> On Mar 14, 2012, at 1:42 PM, Chris Barker wrote: > 1) there are folks that want to do a little python that don't have any > experience or interest in the whole C building thing -- and to get the > compiler on the Mac, you need to register with Mac Developer > connection, then download a MASSIVE binary -- it's not a trivial lift. Not any more. You can install XCode from Mac App store as an application now instead of an installation bundle/image. Also, the membership in the Mac Developer connection is not required. Only if you are going to sign apps for Mac or iOS you need the membership. For a casual user who needs a C compiler and finds XCode on the Mac App store it's not required. Zvezdan From chris.barker at noaa.gov Wed Mar 14 23:30:51 2012 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 14 Mar 2012 15:30:51 -0700 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <513A7E3F-BFAC-4A19-9892-F05E066DC519@computer.org> References: <4F60076F.1080103@oddbird.net> <513A7E3F-BFAC-4A19-9892-F05E066DC519@computer.org> Message-ID: On Wed, Mar 14, 2012 at 3:05 PM, Zvezdan Petkovic wrote: >> 1) there are folks that want to do a little python that don't have any >> experience or interest in the whole C building thing -- and to get the >> compiler on the Mac, you need to register with Mac Developer >> connection, then download a MASSIVE binary -- it's not a trivial lift. > > Not any more. > You can install XCode from Mac App store as an application now instead of an installation bundle/image. nicer -- though I imagine it's still a huge download. > Also, the membership in the Mac Developer connection is not required. > Only if you are going to sign apps for Mac or iOS you need the membership. ?For a casual user who needs a C compiler and finds XCode on the Mac App store it's not required. nice to know. However, the fact remains that there are folks that just want to write some Python code -- Also, aside from the compiler, it's still can be a pain to build stuff that requires dependencies (yes, I know about homebrew, macports, fink -- the point still stands) I think it's important to support that part of the community. NOTE: on Windows, you can simply install the right version of Visual Studio Express, and get building capability there, too -- but there is still a real desire for binaries. -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 Chris.Barker at noaa.gov From p.f.moore at gmail.com Thu Mar 15 00:29:12 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Wed, 14 Mar 2012 23:29:12 +0000 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <4F60EBBC.2060100@ziade.org> References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> Message-ID: On 14 March 2012 19:04, Tarek Ziad? wrote: >> Please can we have a new format that only has a Python version in the >> filename if it matters? > > isn't that supposed to be the source release ? Yes, basically - at least as far as I understand. > Why would someone create a binary release when > it's pure Python ? I wish I knew. But people do - mostly egg format files. But I think this is partly because of the confusion between egg-as-distribution-format vs egg-as-directly-usable-object that PJE alludes to in his emails. If there's a binary egg available, how do I know whether it's needed without trying a source install and seeing if it works? And what about where it does, but doesn't install C accelerators because I have no compiler? The source works, but the binary is better. How would an automated installation process know? Binary installers for pure-Python projects exist, and cause confusion. (Example - IPython, see http://archive.ipython.org/release/0.12/) > or are you thinking about the auto-installable feature > for windows here ? No. I used to care about this, but no longer. I'm happy now to install anything that *can* be installed from source directly, using pip (or pysetup, once it works). > I think there are two different uses cases: > > - install a program or a lib manually -- where an auto-installer makes > sense. > - have a library installed by a tool, where an auto-installer is not really > needed. I'm not sure I'd characterise the cases like that, I tend to think of them as "wants to integrate with system standard policies" vs "wants to use Python specific approaches". But it's the same 2 cases. I used to be in the first camp, but I've switched and these days I'm firmly in the second. > I was thinking bdist_wininst and bdist_msi would stay around for people that > want to create self-installable archives, > and we would discuss a new format that is not self-installable. The key thing for me, as a user, is having packages that I cannot build myself available to me in a format that I can use. And secondarily to have an easy user experience. The following are possible installation scenarios: 1. pip/pysetup install PKG - transparent and simple, for source distributions that are pure-Python or I can build (no external dependencies and I have C installed) 2. pip/pysetup install PKG - new-format supplied by author (I assume the install command will auto-download the new format) 3. download egg/wininst file run converter to create new-format pip/pysetup install new-format-file tidy up the temporary files - egg or wininst supplied by author, assuming converters exist and are supplied with Python (add a "find the converter" step if they are 3rd party) 4. Install as system installer - MSI supplied by author, and I'm installing in system Python. 5. Cry - MSI supplied by author and I want to install in a virtualenv or similar. Basically, it's impossible (or at least, not worth the effort). To give me the best user experience, authors have to start supplying the new format. The hard part is getting authors to take up a new format (after all, they probably want to keep the old format as well, for users who haven't switched to pysetup, so you've just doubled their work). Alternatively, integrate the converters directly into pip/pysetup, so that eggs and wininsts are *transparently* converted on download, making case 3 look just like case 2. But at that point, what's the argument for authors distributing the new format, when the old ones work just as well for new-style users? The technical issues aren't hard, it's the social issues that need careful consideration. Paul. From pje at telecommunity.com Thu Mar 15 04:06:47 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 14 Mar 2012 23:06:47 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> Message-ID: On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: > If there's a binary egg available, how do I know whether it's needed > without trying a source install and seeing if it works? The egg will have a platform string in its name in that case. Otherwise, it'll be just package-version-pyX.X.egg. (Actually, on reflection, I'm not sure I understand your question: "needed" relative to what? to downloading the source version?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Thu Mar 15 09:07:21 2012 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 15 Mar 2012 08:07:21 +0000 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> Message-ID: 2012/3/15 PJ Eby : > On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: >> >> If there's a binary egg available, how do I know whether it's needed >> without trying a source install and seeing if it works? > > > The egg will have a platform string in its name in that case. ?Otherwise, > it'll be just package-version-pyX.X.egg. > > (Actually, on reflection, I'm not sure I understand your question: "needed" > relative to what? ?to downloading the source version?) Correct. In the context of "I'll use source if I can". I "need" a binary if there are C files to compile (even for things like optional speedup code). I guess there's an implied requirement that I can tell what I "need" just by inspection of the types of distribution available.because obviously there's always the option of trying a source install and seeing how it works. In a wider sense, I'm thinking about how something like "pysetup install" should work if binary formats are supported. If a package supplies source, and a variety of eggs, but not wininst or new-format package, then what should pysetup install (or the user, if auto-conversion isn't implemented) choose? From what you say above, the answer appears to be "the egg if its name has a platform string, otherwise the source". That's basically what I was getting at. Thanks, Paul. From nitinkdhiman at gmail.com Thu Mar 15 09:29:09 2012 From: nitinkdhiman at gmail.com (Nitin Dhiman) Date: Thu, 15 Mar 2012 13:59:09 +0530 Subject: [Distutils] easy_install problem In-Reply-To: References: Message-ID: I tried and following is the output. nitin at nitin-desktop:/opt/ros/diamondback/ros$ sudo easy_install -vv -U rosinstall vcstools Searching for rosinstall Reading http://pypi.python.org/simple/rosinstall/ Download error: [Errno -2] Name or service not known -- Some packages may not be found! Reading http://pypi.python.org/simple/rosinstall/ Download error: [Errno -2] Name or service not known -- Some packages may not be found! Couldn't find index page for 'rosinstall' (maybe misspelled?) Scanning index of all packages (this may take a while) Reading http://pypi.python.org/simple/ Download error: [Errno -2] Name or service not known -- Some packages may not be found! No local packages or download links found for rosinstall error: Could not find suitable distribution for Requirement.parse('rosinstall') Just a wild thought, could it be because that i can not access internet from shell while i could do so from browser. May be some settings which are not available to shell from gnome. This is how my network is currently configured: $ cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.20.16.45 gateway 192.20.16.1 netmask 255.255.255.0 On Wed, Mar 14, 2012 at 10:36 PM, PJ Eby wrote: > Try running your command with '-vv' to increase the verbosity, and with > PYDISTUTILS_DEBUG=true in your environment; you may get back more detailed > error information that may assist you in finding out what's happening with > the proxy. > > On Wed, Mar 14, 2012 at 6:10 AM, Nitin Dhiman > wrote: >> >> Greetings, >> My OS is Ubuntu Lucid lynx 10.04, with Python disutils >> python-setuptools version 0.6.10-4ubuntu1 >> >> I am behind proxy. http_proxy and https_proxy is defined as >> http://username:passwd at proxy-ip:port >> >> I am trying to use easy_install to install rosinstall using following >> command: >> >> >> nitin at nitin-desktop:~/Downloads$ sudo easy_install -U rosinstall vcstools >> [sudo] password for nitin: >> Searching for rosinstall >> Reading http://pypi.python.org/simple/rosinstall/ >> Download error: [Errno -2] Name or service not known -- Some packages >> may not be found! >> Reading http://pypi.python.org/simple/rosinstall/ >> Download error: [Errno -2] Name or service not known -- Some packages >> may not be found! >> Couldn't find index page for 'rosinstall' (maybe misspelled?) >> Scanning index of all packages (this may take a while) >> Reading http://pypi.python.org/simple/ >> Download error: [Errno -2] Name or service not known -- Some packages >> may not be found! >> No local packages or download links found for rosinstall >> error: Could not find suitable distribution for >> Requirement.parse('rosinstall') >> >> >> This repeats couple of times. Is this issue related to proxy??? I do >> not face any problem when having a direct internet connnection. >> I had tried using pip also but i gets problems. Following is the >> output of log file. >> >> ?Downloading/unpacking rosinstall >> ? Getting page http://pypi.python.org/simple/rosinstall >> ? Could not fetch URL http://pypi.python.org/simple/rosinstall: >> >> ? Will skip URL http://pypi.python.org/simple/rosinstall when looking >> for download links for rosinstall >> ? Getting page http://pypi.python.org/simple/ >> ? Could not fetch URL http://pypi.python.org/simple/: > [Errno -2] Name or service not known> >> ? Will skip URL http://pypi.python.org/simple/ when looking for >> download links for rosinstall >> ? Cannot fetch index base URL http://pypi.python.org/simple/ >> Cannot find requirement rosinstall, nor fetch index URL >> http://pypi.python.org/simple/ >> Exception information: >> Traceback (most recent call last): >> ? File "/usr/lib/python2.6/dist-packages/pip.py", line 252, in main >> ? ? self.run(options, args) >> ? File "/usr/lib/python2.6/dist-packages/pip.py", line 408, in run >> ? ? requirement_set.install_files(finder, force_root_egg_info=self.bundle) >> ? File "/usr/lib/python2.6/dist-packages/pip.py", line 1750, in >> install_files >> ? ? url = finder.find_requirement(req_to_install, upgrade=self.upgrade) >> ? File "/usr/lib/python2.6/dist-packages/pip.py", line 996, in >> find_requirement >> ? ? url_name = self._find_url_name(Link(self.index_urls[0]), url_name, >> req) >> ? File "/usr/lib/python2.6/dist-packages/pip.py", line 1073, in >> _find_url_name >> ? ? raise DistributionNotFound('Cannot find requirement %s, nor fetch >> index URL %s' % (req, index_url)) >> DistributionNotFound: Cannot find requirement rosinstall, nor fetch >> index URL http://pypi.python.org/simple/ >> >> >> The package I am trying to install is from ROS (www.ros.org) . The >> community of ROS has suggested to ask the solution in this community . >> I hope some one can solve the problem. >> Could this problem be because of any proxy rules???? I am not aware of >> these. >> >> regards >> prince >> _______________________________________________ >> Distutils-SIG maillist ?- ?Distutils-SIG at python.org >> http://mail.python.org/mailman/listinfo/distutils-sig > > From jim at zope.com Thu Mar 15 12:40:36 2012 From: jim at zope.com (Jim Fulton) Date: Thu, 15 Mar 2012 07:40:36 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> Message-ID: On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: > On 14 March 2012 19:04, Tarek Ziad? wrote: >>> Please can we have a new format that only has a Python version in the >>> filename if it matters? >> >> isn't that supposed to be the source release ? > > Yes, basically - at least as far as I understand. > >> Why would someone create a binary release when >> it's pure Python ? > > I wish I knew. But people do - mostly egg format files. But I think > this is partly because of the confusion between > egg-as-distribution-format vs egg-as-directly-usable-object that PJE > alludes to in his emails. I sometimes create platform-independent eggs to indicate a Python-version dependency. Until d2/p, there was no other way to indicate dependence on a particular Python version. Note that the terminology is confusing. I think eggs are defined to be a "binary" distribution format, so eggs containing C extensions are referred to as "platform-specific". You raise a good point about how to deal with optional extensions. There's no meta data to indicate whether there are optional extensions that might guide an automated installer. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From chris.barker at noaa.gov Thu Mar 15 17:03:02 2012 From: chris.barker at noaa.gov (Chris Barker) Date: Thu, 15 Mar 2012 09:03:02 -0700 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> Message-ID: > On 14 March 2012 19:04, Tarek Ziad? wrote: >> Why would someone create a binary release when >> it's pure Python ? There are a lot of users (Windows and Mac anyway) that like a nice point+click installer, and don't know (and shouldn't have to) whether there is any compiled code in there. It's nice to support that. -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 Chris.Barker at noaa.gov From marius at pov.lt Thu Mar 15 17:58:00 2012 From: marius at pov.lt (Marius Gedminas) Date: Thu, 15 Mar 2012 18:58:00 +0200 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> Message-ID: <20120315165800.GA32365@fridge.pov.lt> On Thu, Mar 15, 2012 at 07:40:36AM -0400, Jim Fulton wrote: > On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: > > On 14 March 2012 19:04, Tarek Ziad? wrote: > >>> Please can we have a new format that only has a Python version in the > >>> filename if it matters? > >> > >> isn't that supposed to be the source release ? > > > > Yes, basically - at least as far as I understand. > > > >> Why would someone create a binary release when > >> it's pure Python ? > > > > I wish I knew. But people do - mostly egg format files. But I think > > this is partly because of the confusion between > > egg-as-distribution-format vs egg-as-directly-usable-object that PJE > > alludes to in his emails. > > I sometimes create platform-independent eggs to indicate a Python-version > dependency. Until d2/p, there was no other way to indicate dependence > on a particular Python version. Except for Trove classifiers, of course: 'Programming Language :: Python', 'Programming Language :: Python :: 2', 'Programming Language :: Python :: 2.4', 'Programming Language :: Python :: 2.5', 'Programming Language :: Python :: 2.6', 'Programming Language :: Python :: 2.7', 'Programming Language :: Python :: 3', 'Programming Language :: Python :: 3.1', 'Programming Language :: Python :: 3.2', Or do I misunderstand your requirements? Marius Gedminas -- No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication-applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. -- ALGOL 68 Report -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From jim at zope.com Thu Mar 15 19:19:45 2012 From: jim at zope.com (Jim Fulton) Date: Thu, 15 Mar 2012 14:19:45 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <20120315165800.GA32365@fridge.pov.lt> References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> <20120315165800.GA32365@fridge.pov.lt> Message-ID: On Thu, Mar 15, 2012 at 12:58 PM, Marius Gedminas wrote: > On Thu, Mar 15, 2012 at 07:40:36AM -0400, Jim Fulton wrote: >> On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: >> > On 14 March 2012 19:04, Tarek Ziad? wrote: >> >>> Please can we have a new format that only has a Python version in the >> >>> filename if it matters? >> >> >> >> isn't that supposed to be the source release ? >> > >> > Yes, basically - at least as far as I understand. >> > >> >> Why would someone create a binary release when >> >> it's pure Python ? >> > >> > I wish I knew. But people do - mostly egg format files. But I think >> > this is partly because of the confusion between >> > egg-as-distribution-format vs egg-as-directly-usable-object that PJE >> > alludes to in his emails. >> >> I sometimes create platform-independent eggs to indicate a Python-version >> dependency. ?Until d2/p, there was no other way to indicate dependence >> on a particular Python version. > > Except for Trove classifiers, of course: > > ? ?'Programming Language :: Python', > ? ?'Programming Language :: Python :: 2', > ? ?'Programming Language :: Python :: 2.4', > ? ?'Programming Language :: Python :: 2.5', > ? ?'Programming Language :: Python :: 2.6', > ? ?'Programming Language :: Python :: 2.7', > ? ?'Programming Language :: Python :: 3', > ? ?'Programming Language :: Python :: 3.1', > ? ?'Programming Language :: Python :: 3.2', > > Or do I misunderstand your requirements? None of the tools use Trove classifiers to make decisions about what to download afaik. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From andrea.crotti.0 at gmail.com Fri Mar 16 15:42:09 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Fri, 16 Mar 2012 14:42:09 +0000 Subject: [Distutils] get name of built egg Message-ID: <4F635141.7060905@gmail.com> Given the setuptools magic done by python setup.py bdist_egg is there a way to find out what will be the name of the final egg file? It would be really useful to know for me and I can't find any option to tell bdist_egg to let me know where it will write.. From marius at pov.lt Fri Mar 16 18:53:24 2012 From: marius at pov.lt (Marius Gedminas) Date: Fri, 16 Mar 2012 19:53:24 +0200 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> <20120315165800.GA32365@fridge.pov.lt> Message-ID: <20120316175324.GB5055@fridge.pov.lt> On Thu, Mar 15, 2012 at 02:19:45PM -0400, Jim Fulton wrote: > On Thu, Mar 15, 2012 at 12:58 PM, Marius Gedminas wrote: > > On Thu, Mar 15, 2012 at 07:40:36AM -0400, Jim Fulton wrote: > >> On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: > >> > On 14 March 2012 19:04, Tarek Ziad? wrote: > >> >> Why would someone create a binary release when > >> >> it's pure Python ? > >> > > >> > I wish I knew. But people do - mostly egg format files. But I think > >> > this is partly because of the confusion between > >> > egg-as-distribution-format vs egg-as-directly-usable-object that PJE > >> > alludes to in his emails. > >> > >> I sometimes create platform-independent eggs to indicate a Python-version > >> dependency. ?Until d2/p, there was no other way to indicate dependence > >> on a particular Python version. > > > > Except for Trove classifiers, of course: > > > > ? ?'Programming Language :: Python', > > ? ?'Programming Language :: Python :: 2', > > ? ?'Programming Language :: Python :: 2.4', > > ? ?'Programming Language :: Python :: 2.5', > > ? ?'Programming Language :: Python :: 2.6', > > ? ?'Programming Language :: Python :: 2.7', > > ? ?'Programming Language :: Python :: 3', > > ? ?'Programming Language :: Python :: 3.1', > > ? ?'Programming Language :: Python :: 3.2', > > > > Or do I misunderstand your requirements? > > None of the tools use Trove classifiers to make decisions > about what to download afaik. Do they make decisions based on the presence of versioned .egg files? I'd expect the tools to fall back to the sdist if they couldn't find an .egg for a particular Python version. If I'm right, then uploading binary eggs doesn't help either -- unless you refrain from uploading the sdist to PyPI? Marius Gedminas -- H.323 has much in common with other ITU-T standards - it features a complex binary wire protocol, a nightmarish implementation, and a bulk that can be used to fell medium-to-large predatory animals. -- Anthony Baxter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From ownerscircle at gmail.com Fri Mar 16 18:37:07 2012 From: ownerscircle at gmail.com (PJ Eby) Date: Fri, 16 Mar 2012 13:37:07 -0400 Subject: [Distutils] get name of built egg In-Reply-To: <4F635141.7060905@gmail.com> References: <4F635141.7060905@gmail.com> Message-ID: On Mar 16, 2012 10:42 AM, "Andrea Crotti" wrote: > > Given the setuptools magic done by > python setup.py bdist_egg > > is there a way to find out what will be the name of the final egg file? > It would be really useful to know for me and I can't find any option > to tell bdist_egg to let me know where it will write.. If you just want the file accessible by a script or some larger build process that's invoking the setup script, the easiest way to do it is to specify an empty output directory for the distribution to be built in, instead of 'dist/'. Then, there will only be one file in that directory after running bdist_egg: the egg file. (If you meant some other scenario, then you'll need to explain in more detail what you want.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at zope.com Fri Mar 16 21:12:33 2012 From: jim at zope.com (Jim Fulton) Date: Fri, 16 Mar 2012 16:12:33 -0400 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: <20120316175324.GB5055@fridge.pov.lt> References: <4F60076F.1080103@oddbird.net> <4F6008E6.7020200@ziade.org> <4F60EBBC.2060100@ziade.org> <20120315165800.GA32365@fridge.pov.lt> <20120316175324.GB5055@fridge.pov.lt> Message-ID: On Fri, Mar 16, 2012 at 1:53 PM, Marius Gedminas wrote: > On Thu, Mar 15, 2012 at 02:19:45PM -0400, Jim Fulton wrote: >> On Thu, Mar 15, 2012 at 12:58 PM, Marius Gedminas wrote: >> > On Thu, Mar 15, 2012 at 07:40:36AM -0400, Jim Fulton wrote: >> >> On Wed, Mar 14, 2012 at 7:29 PM, Paul Moore wrote: >> >> > On 14 March 2012 19:04, Tarek Ziad? wrote: >> >> >> Why would someone create a binary release when >> >> >> it's pure Python ? >> >> > >> >> > I wish I knew. But people do - mostly egg format files. But I think >> >> > this is partly because of the confusion between >> >> > egg-as-distribution-format vs egg-as-directly-usable-object that PJE >> >> > alludes to in his emails. >> >> >> >> I sometimes create platform-independent eggs to indicate a Python-version >> >> dependency. ?Until d2/p, there was no other way to indicate dependence >> >> on a particular Python version. >> > >> > Except for Trove classifiers, of course: >> > >> > ? ?'Programming Language :: Python', >> > ? ?'Programming Language :: Python :: 2', >> > ? ?'Programming Language :: Python :: 2.4', >> > ? ?'Programming Language :: Python :: 2.5', >> > ? ?'Programming Language :: Python :: 2.6', >> > ? ?'Programming Language :: Python :: 2.7', >> > ? ?'Programming Language :: Python :: 3', >> > ? ?'Programming Language :: Python :: 3.1', >> > ? ?'Programming Language :: Python :: 3.2', >> > >> > Or do I misunderstand your requirements? >> >> None of the tools use Trove classifiers to make decisions >> about what to download afaik. > > Do they make decisions based on the presence of versioned .egg files? > I'd expect the tools to fall back to the sdist if they couldn't find an > .egg for a particular Python version. ?If I'm right, then uploading > binary eggs doesn't help either -- unless you refrain from uploading the > sdist to PyPI? That's exactly what I do. (I don't do this very often.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From tim at gfxmonk.net Sat Mar 17 02:04:22 2012 From: tim at gfxmonk.net (Tim Cuthbertson) Date: Sat, 17 Mar 2012 12:04:22 +1100 Subject: [Distutils] Running `distribute` without installing it globally Message-ID: Hi all, I'm attempting to create a [zero install](http://0install.net) feed / package for distribute, for the purposes of being able to build software (using distribute) without having to first manually install distribute. Specifically nosetests, but I imagine it will be useful for lots of other software. This means I'll only really want the part of distribute that *builds* software - running 2to3, compiling C extensions if present, etc. If there's a specific subset of distribute I should be using that, it'd be good to know - but for now I'm building the the whole thing and just not invoking the other features. Anyway, the main requirements of a zero install feed are that the program must be relocatable, and must be runnable "as-is", without installing anything to well-known locations. This is similar to wanting to run a built version from within a checked-out workspace, in that the location of the built files is not some special system location. In attempting to do this (specifically for python 3), I've encountered some issues. The first is that `distutils.require("distribute")` doesn't work if distribute is not installed globally. This failed on program startup, because setuptools/package_index.py contains: user_agent = "Python-urllib/%s distribute/%s" % ( sys.version[:3], require('distribute')[0].version ) I've changed this to use setuptools.__version__, which is not the exact same thing but is probably close enough for a user-agent? Otherwise, perhaps the user-agent could be lazy-initted since you'd have little reason to use it if you're just building packages. The second issue is much more surprising: Once I got it running, any invocation would give me the error: $ python3 lib/easy_install.py --help usage: easy_install.py [options] requirement_or_url ... or: easy_install.py --help error: invalid command 'easy_install' I've taken the following line out of setuptools/command/easy_install.py: script_args = ['-q','easy_install', '-v']+argv, and replaced it with just: script_args = argv, I feel surely there was a good reason for this being here in the first place, so I'm curious about why it was broken for me. I've pushed my changes to bitbucket: https://bitbucket.org/gfxmonk/distribute. After these changes, it seems to at least run from an arbitrary directory without being installed globally. After all this, trying to build nosetests (using `python3 setup.py build`) still fails though, unfortunately - it seems to be using the system version of the setup() function, because I get the following warnings: /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown distribution option: 'test_suite' warnings.warn(msg) /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown distribution option: 'use_2to3' warnings.warn(msg) /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown distribution option: 'zip_safe' warnings.warn(msg) /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown distribution option: 'entry_points' warnings.warn(msg) ..and the built library gets syntax on errors when run under py3, presumably because py3 didn't actually run. Any idea how to get some more information on what path is being taken during the build process and why it's not invoking the distribute hotness? Cheers, - Tim. From andrea.crotti.0 at gmail.com Sat Mar 17 23:57:14 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Sat, 17 Mar 2012 22:57:14 +0000 Subject: [Distutils] get name of built egg In-Reply-To: References: <4F635141.7060905@gmail.com> Message-ID: <4F6516CA.9040304@gmail.com> On 03/16/2012 05:37 PM, PJ Eby wrote: > > On Mar 16, 2012 10:42 AM, "Andrea Crotti" > wrote: > > > > Given the setuptools magic done by > > python setup.py bdist_egg > > > > is there a way to find out what will be the name of the final egg file? > > It would be really useful to know for me and I can't find any option > > to tell bdist_egg to let me know where it will write.. > > If you just want the file accessible by a script or some larger build > process that's invoking the setup script, the easiest way to do it is > to specify an empty output directory for the distribution to be built > in, instead of 'dist/'. Then, there will only be one file in that > directory after running bdist_egg: the egg file. > > (If you meant some other scenario, then you'll need to explain in more > detail what you want.) > That would be the scenario yes, but it's quite a lame solution imho :/ I mean setuptools generates the name of this file somehow while building the egg file, is that impossible to retrieve it before or after actually creating it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at gfxmonk.net Sun Mar 18 01:08:18 2012 From: tim at gfxmonk.net (Tim Cuthbertson) Date: Sun, 18 Mar 2012 11:08:18 +1100 Subject: [Distutils] Running `distribute` without installing it globally In-Reply-To: References: Message-ID: On Sat, Mar 17, 2012 at 12:04 PM, Tim Cuthbertson wrote: > Hi all, > > I'm attempting to create a [zero install](http://0install.net) feed / > package for distribute, for the purposes of being able to build > software (using distribute) without having to first manually install > distribute. Specifically nosetests, but I imagine it will be useful > for lots of other software. > > This means I'll only really want the part of distribute that *builds* > software - running 2to3, compiling C extensions if present, etc. If > there's a specific subset of distribute I should be using that, it'd > be good to know - but for now I'm building the the whole thing and > just not invoking the other features. > > Anyway, the main requirements of a zero install feed are that the > program must be relocatable, and must be runnable "as-is", without > installing anything to well-known locations. This is similar to > wanting to run a built version from within a checked-out workspace, in > that the location of the built files is not some special system > location. > > > > > In attempting to do this (specifically for python 3), I've encountered > some issues. The first is that `distutils.require("distribute")` > doesn't work if distribute is not installed globally. This failed on > program startup, because setuptools/package_index.py contains: > > user_agent = "Python-urllib/%s distribute/%s" % ( > ? sys.version[:3], require('distribute')[0].version > ?) > > I've changed this to use setuptools.__version__, which is not the > exact same thing but is probably close enough for a user-agent? > Otherwise, perhaps the user-agent could be lazy-initted since you'd > have little reason to use it if you're just building packages. > > > > > > The second issue is much more surprising: Once I got it running, any > invocation would give me the error: > > $ python3 lib/easy_install.py --help > usage: easy_install.py [options] requirement_or_url ... > ? or: easy_install.py --help > > error: invalid command 'easy_install' > > > I've taken the following line out of setuptools/command/easy_install.py: > ? ?script_args = ['-q','easy_install', '-v']+argv, > and replaced it with just: > ? ?script_args = argv, > > I feel surely there was a good reason for this being here in the first > place, so I'm curious about why it was broken for me. > > I've pushed my changes to bitbucket: > https://bitbucket.org/gfxmonk/distribute. After these changes, it > seems to at least run from an arbitrary directory without being > installed globally. > > > > > After all this, trying to build nosetests (using `python3 setup.py > build`) still fails though, unfortunately - it seems to be using the > system version of the setup() function, because I get the following > warnings: > > /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown > distribution option: 'test_suite' > ?warnings.warn(msg) > /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown > distribution option: 'use_2to3' > ?warnings.warn(msg) > /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown > distribution option: 'zip_safe' > ?warnings.warn(msg) > /usr/lib/python3.2/distutils/dist.py:257: UserWarning: Unknown > distribution option: 'entry_points' > ?warnings.warn(msg) > > > ..and the built library gets syntax on errors when run under py3, > presumably because py3 didn't actually run. Any idea how to get some > more information on what path is being taken during the build process > and why it's not invoking the distribute hotness? > > Cheers, > ?- Tim. So I'm not entirely sure *how* this happened, but it seems that after switching to use the "install" command instead of "build", none of these problems occur. I'm pretty confused as to why, but certainly not complaining. If anybody is interested in zero install, I've now got a working feed for distribute here: http://gfxmonk.net/dist/0install/python-distribute.xml If you're curious as tot he point of all this, it means that one can depend upon distribute to build source packages into python2 and python3 "binary" implementations (not really binary since they're just relocatable python code) without having to manually install distribute for either python 2 or 3. Which I've made use of for the `nosetests` feed: http://gfxmonk.net/dist/0install/nose.xml Cheers, - Tim. From ownerscircle at gmail.com Sun Mar 18 00:58:37 2012 From: ownerscircle at gmail.com (PJ Eby) Date: Sat, 17 Mar 2012 19:58:37 -0400 Subject: [Distutils] get name of built egg In-Reply-To: <4F6516CA.9040304@gmail.com> References: <4F635141.7060905@gmail.com> <4F6516CA.9040304@gmail.com> Message-ID: Well, you can use "setup.py --name --version" to get the name and version. You can run "setup.py egg_info" pointed to some target directory to inspect the PKG-INFO. There are quite a few ways to get the information. I don't yet understand what criteria you have that make one of these ways any better than another. If you need the name of the file it's generating so you can access that file, then I'm not sure why you care *in advance* of it actually generating the file. ;-) On Sat, Mar 17, 2012 at 6:57 PM, Andrea Crotti wrote: > On 03/16/2012 05:37 PM, PJ Eby wrote: > > On Mar 16, 2012 10:42 AM, "Andrea Crotti" > wrote: > > > > Given the setuptools magic done by > > python setup.py bdist_egg > > > > is there a way to find out what will be the name of the final egg file? > > It would be really useful to know for me and I can't find any option > > to tell bdist_egg to let me know where it will write.. > > If you just want the file accessible by a script or some larger build > process that's invoking the setup script, the easiest way to do it is to > specify an empty output directory for the distribution to be built in, > instead of 'dist/'. Then, there will only be one file in that directory > after running bdist_egg: the egg file. > > (If you meant some other scenario, then you'll need to explain in more > detail what you want.) > > > That would be the scenario yes, but it's quite a lame solution imho :/ > I mean setuptools generates the name of this file somehow while building > the egg file, > is that impossible to retrieve it before or after actually creating it? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.braga at gmail.com Sun Mar 18 01:49:47 2012 From: bruno.braga at gmail.com (Bruno Braga) Date: Sun, 18 Mar 2012 10:49:47 +1000 Subject: [Distutils] setup.py, data_files and i18n In-Reply-To: References: Message-ID: <9ADCE23E2D1D4A8382D448195F937C8C@gmail.com> Hei Erik, Thanks? That does the trick! But there is still an issue regarding where the files will be installed. On Ubuntu, it goes to: /usr/local/share/locale and this does not work because gettext looks at: /usr/share/locale On mac (lion), however, it works. The installed failed go to: /System/Library/Frameworks/Python.framework/Versions/2.7/share/locale/ And gettext looks at: /opt/local/share/locale Even though, python seems to pick up the l10n right. The same does not happen in Linux, unless I force the setup.py to install in /usr path? How can I tell python to look for that directory in particular instead of the default? My concern here is that I should not hard-code this path in the gettext.translation() method, which would then not work for other people with non-standard locations, or on mac, or on Windows? I read about setting up m4 alike strings in python code that would be replaced by distutils upon compilation, but I could not find any reference for that, neither if that is a solution for my problem. Thanks for your help. -- Braga, Bruno www.brunobraga.net (http://www.brunobraga.net/) bruno.braga at gmail.com (mailto:bruno.braga at gmail.com) On Tuesday, 6 March 2012 at 5:35 AM, Erik Bray wrote: > On Thu, Mar 1, 2012 at 11:02 PM, BRAGA, Bruno wrote: > > Hi, > > > > I am working on a project written in Python, and I would like to use i18n > > functionality, but I am having some issues with it, more specifically > > regarding the .mo files location, and I was hoping someone here could point > > me in the right direction. > > > > (1) i18n mo files location > > > > Basically, I already know how to translate contents with gettext, but I got > > stuck with the fact that it, by default, looks at > > /usr/share/locale/{language} (in Linux), but the setup.py install data_files > > into /usr/local/share/... unless I forcibly use absolute paths toward the > > location where the files should be. > > > > (2) install_data.data_files > > > > Also, I am having a problem to install the data_files, because the > > install_data command is never called. I made it work before, but I don't > > understand what I am missing that worked before and not now. > > > > Here is the setup.py script: > > https://github.com/brunobraga/termsaver/blob/master/setup.py > > > > And this is the i18n module I am using as base for localizing all text in > > the application: > > https://github.com/brunobraga/termsaver/blob/master/termsaverlib/i18n.py > > > > Here is the output of a clean install: > > > > bruno at development3;~$ sudo python setup.py install --record > > /tmp/termsaver.install.record.txt > > [sudo] password for bruno: > > running install > > running build > > running build_py > > creating build > > creating build/lib.linux-i686-2.7 > > creating build/lib.linux-i686-2.7/termsaverlib > > copying termsaverlib/constants.py -> build/lib.linux-i686-2.7/termsaverlib > > copying termsaverlib/i18n.py -> build/lib.linux-i686-2.7/termsaverlib > > copying termsaverlib/common.py -> build/lib.linux-i686-2.7/termsaverlib > > copying termsaverlib/exception.py -> build/lib.linux-i686-2.7/termsaverlib > > copying termsaverlib/__init__.py -> build/lib.linux-i686-2.7/termsaverlib > > creating build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/programmer.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/rssfeed.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/rfc.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/urlfetcher.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/jokes4all.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/dot.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/__init__.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/asciiartfarts.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/quotes4all.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > copying termsaverlib/screen/randtxt.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen > > creating build/lib.linux-i686-2.7/termsaverlib/screen/base > > copying termsaverlib/screen/base/rssfeed.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/base > > copying termsaverlib/screen/base/urlfetcher.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/base > > copying termsaverlib/screen/base/filereader.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/base > > copying termsaverlib/screen/base/__init__.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/base > > creating build/lib.linux-i686-2.7/termsaverlib/screen/helper > > copying termsaverlib/screen/helper/position.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/helper > > copying termsaverlib/screen/helper/urlfetcher.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/helper > > copying termsaverlib/screen/helper/typing.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/helper > > copying termsaverlib/screen/helper/xmlreader.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/helper > > copying termsaverlib/screen/helper/__init__.py -> > > build/lib.linux-i686-2.7/termsaverlib/screen/helper > > running build_scripts > > creating build/scripts-2.7 > > copying and adjusting termsaver -> build/scripts-2.7 > > changing mode of build/scripts-2.7/termsaver from 644 to 755 > > running build_trans > > Compiling locale/ja.po > > Compiling locale/en.po > > running install_lib > > creating /usr/local/lib/python2.7/dist-packages/termsaverlib > > copying build/lib.linux-i686-2.7/termsaverlib/constants.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib > > creating /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/programmer.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/rssfeed.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/rfc.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/urlfetcher.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/jokes4all.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/dot.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > creating /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base > > copying build/lib.linux-i686-2.7/termsaverlib/screen/base/rssfeed.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base > > copying build/lib.linux-i686-2.7/termsaverlib/screen/base/urlfetcher.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base > > copying build/lib.linux-i686-2.7/termsaverlib/screen/base/filereader.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base > > copying build/lib.linux-i686-2.7/termsaverlib/screen/base/__init__.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base > > copying build/lib.linux-i686-2.7/termsaverlib/screen/__init__.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/asciiartfarts.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > creating /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper > > copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/position.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper > > copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/urlfetcher.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper > > copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/typing.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper > > copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/xmlreader.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper > > copying build/lib.linux-i686-2.7/termsaverlib/screen/helper/__init__.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper > > copying build/lib.linux-i686-2.7/termsaverlib/screen/quotes4all.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/screen/randtxt.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen > > copying build/lib.linux-i686-2.7/termsaverlib/i18n.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib > > copying build/lib.linux-i686-2.7/termsaverlib/common.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib > > copying build/lib.linux-i686-2.7/termsaverlib/exception.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib > > copying build/lib.linux-i686-2.7/termsaverlib/__init__.py -> > > /usr/local/lib/python2.7/dist-packages/termsaverlib > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/constants.py to > > constants.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/programmer.py to > > programmer.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/rssfeed.py to > > rssfeed.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/rfc.py to rfc.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/urlfetcher.py to > > urlfetcher.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/jokes4all.py to > > jokes4all.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/dot.py to dot.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/rssfeed.py > > to rssfeed.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/urlfetcher.py > > to urlfetcher.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/filereader.py > > to filereader.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/base/__init__.py > > to __init__.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/__init__.py to > > __init__.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/asciiartfarts.py > > to asciiartfarts.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/position.py > > to position.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/urlfetcher.py > > to urlfetcher.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/typing.py > > to typing.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/xmlreader.py > > to xmlreader.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/helper/__init__.py > > to __init__.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/quotes4all.py to > > quotes4all.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/screen/randtxt.py to > > randtxt.pyc > > byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/i18n.py > > to i18n.pyc > > byte-compiling /usr/local/lib/python2.7/dist-packages/termsaverlib/common.py > > to common.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/exception.py to > > exception.pyc > > byte-compiling > > /usr/local/lib/python2.7/dist-packages/termsaverlib/__init__.py to > > __init__.pyc > > running install_scripts > > copying build/scripts-2.7/termsaver -> /usr/local/bin > > changing mode of /usr/local/bin/termsaver to 755 > > running install_egg_info > > Writing /usr/local/lib/python2.7/dist-packages/termsaver-0.1_beta.egg-info > > writing list of installed files to '/tmp/termsaver.install.record.txt' > > Thank you for trying termsaver. > > bruno at development3;~$ > > > > > > Any help is much appreciated. I found very hard to do anything with > > distutils unless I open the source and see by myself what it can do or > > not... I was hoping there is a better way. > > > > Thank you in advance, > > Unfortunately, the install command won't actually run the install_data > command as a sub-command unless a non-empty list was passed to > data_files command in setup(). > > But I don't think your custom InstallData command is particularly > necessary. Try removing InstallData and instead do something like > this: > > data_files = [(os.path.join('share', 'locale', lang[:-3], 'LC_MESSAGES'), > [os.path.join('build', 'locale', lang[:-3], 'LC_MESSAGES', > 'termsaver.mo')]) > for lang in os.listdir('locale')] > > and > > setup( > ... > data_files=data_files, > ...) > > That should do what you're trying to do. > > Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkvilekval at gmail.com Tue Mar 20 20:10:01 2012 From: kkvilekval at gmail.com (kgk) Date: Tue, 20 Mar 2012 12:10:01 -0700 Subject: [Distutils] specify manifest template other than MANIFEST.in Message-ID: I would like to keep several related distributions in a single top level directory. In order to do the proper packaging, each package will need it's own MANIFEST.in The docs seems to suggest you can override the default name MANIFEST.in, however, I cannot seem to find an option or parameter to do so. Thanks for any pointers. Kris -- Kristian G. Kvilekval (kkvilekval at gmail.com) 805-636-1599 From merwok at netwok.org Wed Mar 21 03:22:10 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Tue, 20 Mar 2012 22:22:10 -0400 Subject: [Distutils] specify manifest template other than MANIFEST.in In-Reply-To: References: Message-ID: <4F693B52.2020202@netwok.org> Hi, Le 20/03/2012 15:10, kgk a ?crit : > The docs seems to suggest you can override the default name MANIFEST.in, Correct. I tried finding which part of the doc hinted about that to see if I could improve it and could not find it! Do you have the link? > however, I cannot seem to find an option or parameter to do so. Manifests and manifests templates are only used by the sdist command. If you run ?python setup.py sdist -h?, you?ll find the --template/-t option. MANIFEST and MANIFEST.in can?t be found from the index pages in the Python docs; I will fix that. Regards From tkruse at willowgarage.com Wed Mar 21 07:22:46 2012 From: tkruse at willowgarage.com (Thibault Kruse) Date: Tue, 20 Mar 2012 23:22:46 -0700 Subject: [Distutils] bash completion files with easy_install Message-ID: Hi, I am confused about how to provide bash completion files for users of a program to be installed via setuptools. I am working with Ubuntu Lucid mainly, and I have a setup.py like this: setup(... data_files=[('/etc/bash_completion.d', ['contrib/mytool.bash'])]) And also a MANIFEST.in with this include contrib/mytool.bash as a workaround for this problem: http://stackoverflow.com/questions/2994396/python-distutils-does-not-include-data-files Now what happens in Ubuntu Lucid is that easy_install will fail with a SandboxViolation for these files if I easy_install the software. pip install however does not fail. I do not want to force users to use pip, and I am not sure whether easy_install is doing the right thing in using a sandbox. Also i have no idea what will happen on windows machines, where no /etc exists, and no bash exists neither. So can somebody here tell me how I should approach this problem? If anyone wants to reproduce, try this: sudo easy_install -U rosinstall==0.6.9 regards, Thibault -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkvilekval at gmail.com Wed Mar 21 21:22:58 2012 From: kkvilekval at gmail.com (kgk) Date: Wed, 21 Mar 2012 13:22:58 -0700 Subject: [Distutils] distutils2 1.0a4 and simple package Message-ID: I am trying distutils2 cannot get anything to start.. The doc[1] and [2] suggest that one should simply from distutils2.core import setup However, this does not seem to work anymore. Is there a newer way, or is it a bug? Thanks [1] http://docs.python.org/dev/packaging/ [2]http://packages.python.org/Distutils2/distutils/setupscript.html -- Kristian G. Kvilekval (kkvilekval at gmail.com) 805-636-1599 From kkvilekval at gmail.com Wed Mar 21 22:14:42 2012 From: kkvilekval at gmail.com (kgk) Date: Wed, 21 Mar 2012 14:14:42 -0700 Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: References: Message-ID: Thanks for the pointer, is there anyway to use another filename other than setup.cfg? I am trying to build several related package from a common root? On Wed, Mar 21, 2012 at 1:57 PM, Thibault Kruse wrote: > Seems that docu is outdated, as far as I understand the future of disutils2 > is in the setup.cfg instead of a setup.py: > > http://docs.python.org/dev/packaging/setupcfg.html > > though that doc could probably still be improved a bit. > > > On Wed, Mar 21, 2012 at 1:22 PM, kgk wrote: >> >> I am trying distutils2 cannot get anything to start.. The doc[1] and [2] >> suggest that one should simply >> >> from distutils2.core import setup >> >> >> However, this does not seem to work anymore. >> Is there a newer way, or is it a bug? >> >> Thanks >> >> >> [1] http://docs.python.org/dev/packaging/ >> [2]http://packages.python.org/Distutils2/distutils/setupscript.html >> >> -- >> Kristian G. Kvilekval (kkvilekval at gmail.com) 805-636-1599 >> _______________________________________________ >> Distutils-SIG maillist ?- ?Distutils-SIG at python.org >> http://mail.python.org/mailman/listinfo/distutils-sig > > -- Kristian G. Kvilekval (kkvilekval at gmail.com) 805-636-1599 From kkvilekval at gmail.com Thu Mar 22 02:36:44 2012 From: kkvilekval at gmail.com (kgk) Date: Wed, 21 Mar 2012 18:36:44 -0700 Subject: [Distutils] Fwd: specify manifest template other than MANIFEST.in In-Reply-To: References: <4F693B52.2020202@netwok.org> Message-ID: On Tue, Mar 20, 2012 at 7:22 PM, ?ric Araujo wrote: > Hi, > > Le 20/03/2012 15:10, kgk a ?crit : >> The docs seems to suggest you can override the default name MANIFEST.in, > Correct. ?I tried finding which part of the doc hinted about that to see > if I could improve it and could not find it! ?Do you have the link? http://docs.python.org/distutils/sourcedist.html#manifest-related-options >> however, I cannot seem to find an option or parameter to do so. > Manifests and manifests templates are only used by the sdist command. > If you run ?python setup.py sdist -h?, you?ll find the --template/-t option. I am trying to run sdist throught distrubute or setuptools, I didn';t see that options. ?In fact, 'sdist -h' was the first thing I tried. ?I will try with stock distutils and see if it is there. > MANIFEST and MANIFEST.in can?t be found from the index pages in the > Python docs; I will fix that. > Thanks, -- Kristian G. Kvilekval (kkvilekval at gmail.com) 805-636-1599 -- Kristian G. Kvilekval (kkvilekval at gmail.com) 805-636-1599 From merwok at netwok.org Thu Mar 22 03:19:19 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 21 Mar 2012 22:19:19 -0400 Subject: [Distutils] Fwd: specify manifest template other than MANIFEST.in In-Reply-To: References: <4F693B52.2020202@netwok.org> Message-ID: <4F6A8C27.6010908@netwok.org> Hello, >>> The docs seems to suggest you can override the default name MANIFEST.in, >> Correct. I tried finding which part of the doc hinted about that to see >> if I could improve it and could not find it! Do you have the link? > http://docs.python.org/distutils/sourcedist.html#manifest-related-options That?s definitely lacking, I?ll add the other options to that section. >>> however, I cannot seem to find an option or parameter to do so. >> Manifests and manifests templates are only used by the sdist command. >> If you run ?python setup.py sdist -h?, you?ll find the --template/-t option. > I am trying to run sdist throught distrubute or setuptools, I didn';t see that > options. In fact, 'sdist -h' was the first thing I tried. I will try > with stock distutils and see if it is there. >From a quick look at the code setuptools? sdist command ignores MANIFEST.in and MANIFEST altogether and takes the list of files from the version control system. Cheers From merwok at netwok.org Thu Mar 22 03:33:29 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 21 Mar 2012 22:33:29 -0400 Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: References: Message-ID: <4F6A8F79.3090809@netwok.org> Hi, Sorry about that: the doc is very outdated and I have a ton of things to update, fix and expand. I have changed http://bugs.python.org/issue12779 tracks my progress. To get started with d2, create a setup.cfg file as documented in the packaging/setupcfg page and run the pysetup script to see available actions and commands. Regards From merwok at netwok.org Thu Mar 22 04:16:07 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 21 Mar 2012 23:16:07 -0400 Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: References: Message-ID: <4F6A9977.3000507@netwok.org> Message was sent incomplete. I meant to say: I have changed around 1200 lines and I?m really not done. From merwok at netwok.org Thu Mar 22 04:27:37 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 21 Mar 2012 23:27:37 -0400 Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: References: Message-ID: <4F6A9C29.50507@netwok.org> > Thanks for the pointer, is there anyway to use another filename other > than setup.cfg? > I am trying to build several related package from a common root? In the current code the filename must be setup.cfg. I think the rise of distributed version control systems and usable packaging tools like pip and buildout (and setuptools? namespace package feature) have encouraged the separation of projects into separate libraries, each one with its repository and setup.py file. That may be the reason why setup.cfg is hard-coded in distutils2. What do other people think about this? Is the ability to create more than one Python distribution from one directory something we really need? (MAL: I think you use a similar system for your mx releases, please ignore this if I remembered wrong.) Regards From erik.m.bray at gmail.com Thu Mar 22 16:53:09 2012 From: erik.m.bray at gmail.com (Erik Bray) Date: Thu, 22 Mar 2012 11:53:09 -0400 Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: <4F6A9C29.50507@netwok.org> References: <4F6A9C29.50507@netwok.org> Message-ID: On Wed, Mar 21, 2012 at 11:27 PM, ?ric Araujo wrote: >> Thanks for the pointer, is there anyway to use another filename other >> than setup.cfg? >> I am trying to build several related package from a common root? > In the current code the filename must be setup.cfg. ?I think the rise of > distributed version control systems and usable packaging tools like pip > and buildout (and setuptools? namespace package feature) have encouraged > the separation of projects into separate libraries, each one with its > repository and setup.py file. ?That may be the reason why setup.cfg is > hard-coded in distutils2. > > What do other people think about this? ?Is the ability to create more > than one Python distribution from one directory something we really need? This is a use case I've had twice in the past, if I understand correctly at least. In both cases a fair bit of evil hackery was employed to make it possible in distutils (actually setuptools). So it can be done, but it gets ugly, and can cause some surprisingly problems, most of which I can't even think of at the moment. What I can say is that the take away lesson of that experiment was to not do that, and to just break everything into separately distributed packages. Erik From jim at zope.com Thu Mar 22 17:05:10 2012 From: jim at zope.com (Jim Fulton) Date: Thu, 22 Mar 2012 12:05:10 -0400 Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: <4F6A9C29.50507@netwok.org> References: <4F6A9C29.50507@netwok.org> Message-ID: On Wed, Mar 21, 2012 at 11:27 PM, ?ric Araujo wrote: >> Thanks for the pointer, is there anyway to use another filename other >> than setup.cfg? >> I am trying to build several related package from a common root? > In the current code the filename must be setup.cfg. ?I think the rise of > distributed version control systems and usable packaging tools like pip > and buildout (and setuptools? namespace package feature) have encouraged > the separation of projects into separate libraries, each one with its > repository and setup.py file. ?That may be the reason why setup.cfg is > hard-coded in distutils2. It was likewise awkward to name setup.py anything other than setup.py. I have a few VCS projects that contain multiple Python projects in separate directories: http://svn.zope.org/zc.buildout/trunk/ http://svn.zope.org/bobo/trunk/ This has worked fine for me. I might like more flexibility, not sure, but the current limitation probably makes installers simpler, which is worthwhile imo. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From kkvilekval at gmail.com Thu Mar 22 18:54:56 2012 From: kkvilekval at gmail.com (kristian kvilekval) Date: Thu, 22 Mar 2012 10:54:56 -0700 (PDT) Subject: [Distutils] distutils2 1.0a4 and simple package In-Reply-To: <4F6A9C29.50507@netwok.org> References: <4F6A9C29.50507@netwok.org> Message-ID: <18511015.64.1332438896435.JavaMail.geo-discussion-forums@ynjw14> This is exactly the situation I have.. A single project with client and server side libraries. The entire project is in a single VCS repository. On Wednesday, March 21, 2012 8:27:37 PM UTC-7, ?ric Araujo wrote: > > > Thanks for the pointer, is there anyway to use another filename other > > than setup.cfg? > > I am trying to build several related package from a common root? > In the current code the filename must be setup.cfg. I think the rise of > distributed version control systems and usable packaging tools like pip > and buildout (and setuptools? namespace package feature) have encouraged > the separation of projects into separate libraries, each one with its > repository and setup.py file. That may be the reason why setup.cfg is > hard-coded in distutils2. > > What do other people think about this? Is the ability to create more > than one Python distribution from one directory something we really need? > > We would like to build separate distributions for the client and server. >From my standpoint, I would like to build them together as they share some common directories (i.e. config, docs and readme's) > (MAL: I think you use a similar system for your mx releases, please > ignore this if I remembered wrong.) > > Regards > ______________________________?_________________ > Distutils-SIG maillist - Distutils-SIG at python.org > http://mail.python.org/?mailman/listinfo/distutils-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robhealey1 at gmail.com Fri Mar 23 08:17:22 2012 From: robhealey1 at gmail.com (Rob Healey) Date: Fri, 23 Mar 2012 00:17:22 -0700 Subject: [Distutils] greetings, first email... Message-ID: Greetings: This is my introductory email in writing for the first time! Of course, I am very new to DistUtils and creating my first setup.py file. I have a helper in creating this first setup.py file, but he only knows more than I do... We are stuck on this problem, and I was hoping to see if we could get some help??? Here is what is happening: [Frog at PouncingAliens geps0065]$ python setup.py sdist running sdist running check Merging translations into data/gramps.desktop. Merging translations into data/gramps.xml. CREATED data/gramps.xml Merging translations into data/gramps.keys. CREATED ./data/gramps.keys Traceback (most recent call last): File "setup.py", line 487, in main() File "setup.py", line 483, in main 'uninstall': GrampsUninstall} File "/usr/lib64/python2.7/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/sdist.py", line 160, in run self.get_file_list() File "/usr/lib64/python2.7/distutils/command/sdist.py", line 200, in get_file_list self.add_defaults() File "/usr/lib64/python2.7/distutils/command/sdist.py", line 256, in add_defaults build_py = self.get_finalized_command('build_py') File "/usr/lib64/python2.7/distutils/cmd.py", line 312, in get_finalized_command cmd_obj.ensure_finalized() File "/usr/lib64/python2.7/distutils/cmd.py", line 109, in ensure_finalized self.finalize_options() File "/usr/lib64/python2.7/distutils/command/build_py.py", line 46, in finalize_options ('force', 'force')) File "/usr/lib64/python2.7/distutils/cmd.py", line 302, in set_undefined_options getattr(src_cmd_obj, src_option)) File "/usr/lib64/python2.7/distutils/cmd.py", line 105, in __getattr__ raise AttributeError, attr AttributeError: build_lib Could you please explain what this build_lib problem comes from and what I might need to get over it? -- Sincerely yours, Rob G. Healey -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at rpatterson.net Sat Mar 24 20:56:36 2012 From: me at rpatterson.net (Ross Patterson) Date: Sat, 24 Mar 2012 12:56:36 -0700 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> Message-ID: <871uohpybv.fsf@transitory.lefae.org> Jim Fulton writes: > On Tue, Jan 19, 2010 at 11:00 AM, Reinout van Rees wrote: >> On 01/19/2010 01:06 PM, Jim Fulton wrote: >>> >>> On Tue, Jan 19, 2010 at 5:15 AM, Chris Withers >>> ?wrote: >>>> >>>> Hi All, >>>> >>>> I'm wondering what the state of play is with the following branches: >>>> >>>> reinout-scripts >>> >>> Not sure. I need to review this. >> >> Do you need me to make a fresh branch off the current trunk? > > No I've run into the problem of buildout not installing distutils `scritps` many times. This means I can't use buildout when I would like to. It's also worth noting that pip handles this properly. At the moment, I'm writing a buildout tutorial whose aim is to help developers using Python understand the utility and core concepts of buildout. It's really unfortunate I can't tell them to do use the following `buildout.cfg` to get the `docutils` scripts in an isolated buildout: [buildout] parts = docutils [docutils] recipe = zc.recipe.egg Can we possibly get this branch merged and a release made? Ross From cyounkins at gmail.com Sun Mar 25 05:26:15 2012 From: cyounkins at gmail.com (Craig Younkins) Date: Sat, 24 Mar 2012 23:26:15 -0400 Subject: [Distutils] Buildout - Pass parameter to interpreter Message-ID: I want to run my code with the -3 flag of the 2.6 interpreter. The proxy script that buildout's zc.recipe.egg:scripts generates does not accept arbitrary interpreter arguments. How can I pass the -3 flag to the proxy script or otherwise run with the -3 flag? Thanks! Craig Younkins -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrism at plope.com Sun Mar 25 07:47:50 2012 From: chrism at plope.com (Chris McDonough) Date: Sun, 25 Mar 2012 01:47:50 -0400 Subject: [Distutils] packaging docs Message-ID: <1332654470.3640.4.camel@thinko> What state are the docs for "packaging" in right now? Of: http://docs.python.org/dev/packaging/setupcfg.html and http://docs.python.org/dev/packaging/introduction.html ... the latter comes directly after the former in navigation order. The former describes setup.cfg-driven and presumably pysetup-driven stuff, but the latter goes on to discuss setup.py syntax and looks like it might be distutils docs with a bit of search-and-replace done. - C From jim at zope.com Sun Mar 25 16:28:24 2012 From: jim at zope.com (Jim Fulton) Date: Sun, 25 Mar 2012 10:28:24 -0400 Subject: [Distutils] Buildout - Pass parameter to interpreter In-Reply-To: References: Message-ID: On Sat, Mar 24, 2012 at 11:26 PM, Craig Younkins wrote: > I want to run my code with the -3 flag of the 2.6 interpreter. The proxy > script that buildout's zc.recipe.egg:scripts generates does not accept > arbitrary interpreter arguments. How can I pass the -3 flag to the proxy > script or otherwise run with the -3 flag? Thanks! zc.recipe.egg doesn't let you control Python arguments in generated scripts. I wish it did. You could derive a recipe that did. (The easiest way to do this would probably be to let the low-level buildout api generate the script and then edit the script with the derived recipe.) I wonder if someone has already done this. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From reinout at vanrees.org Sun Mar 25 17:31:36 2012 From: reinout at vanrees.org (Reinout van Rees) Date: Sun, 25 Mar 2012 17:31:36 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: <871uohpybv.fsf@transitory.lefae.org> References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On 24-03-12 20:56, Ross Patterson wrote: > Can we possibly get this branch merged and a release made? From what I remembered from 2.5 year ago was that the fix was pretty small. I think I only had to call some setuptools function, basically. Would it be an idea to move zc.buildout out of the zope svn repo into github? It is quite central to many non-zope projects and nobody outside of zope is going to bother with a contributor agreement, I think. And some extra outside effort into buildout would be nice. A good thing about github (or xxx or yyy) would be the ease of pull requests. And a pull request coupled with a visible bug report "scripts don't work" stands more chance of being included than a 2.5 year old simple fix in some branch with some old mailinglist messages. And... I'd love a list of current maintainers of zc.buildout that are allowed to commit to trunk. iirc Jim only works on the python 3 port ("1.5.x is too hard to understand now") and the 1.5.x trunk itself hasn't seen any development lately as far as I could see, despite people being stuck on 1.4.x. So... who's maintaining buildout right now? Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout at vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" From jim at zope.com Sun Mar 25 19:39:22 2012 From: jim at zope.com (Jim Fulton) Date: Sun, 25 Mar 2012 13:39:22 -0400 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees wrote: > On 24-03-12 20:56, Ross Patterson wrote: >> >> Can we possibly get this branch merged and a release made? > > > From what I remembered from 2.5 year ago was that the fix was pretty small. I guess that depends on what you men by small. I don't consider the change small. I would call it straight forward. I wish this had gotten merged before the 1.5 changes. I'm sorry. > I think I only had to call some setuptools function, basically. Looks like more than that. > Would it be an idea to move zc.buildout out of the zope svn repo into > github? Yes. In fact, I was just looking at that. Github's review mechanism is particularly attractive. (AFAICT, bitbucket doesn't have a review/comment process like github's. All I see is the ability to accept or reject pull requests. I only know either from reading docs. If I'm mistaken, please correct me, as the review process is what makes me lean toword github.) > It is quite central to many non-zope projects and nobody outside of > zope is going to bother with a contributor agreement, I think. Yes, although I don't think that's the main problem. (Don't argue this with me, it's just an opinion. :) > And some > extra outside effort into buildout would be nice. Absolutely. I think the code needs a drastic simplification to enable that. > A good thing about github (or xxx or yyy) would be the ease of pull > requests. And a pull request coupled with a visible bug report "scripts > don't work" stands more chance of being included than a 2.5 year old simple > fix in some branch with some old mailinglist messages. Not sure about that. I think the integrated review support would definitely be accretive. > And... I'd love a list of current maintainers of zc.buildout that are > allowed to commit to trunk. Um, any svn.zope.org committer is technically allowed. I realize that's not what you're asking, but ... > iirc Jim only works on the python 3 port Not intentionally. :) > ("1.5.x > is too hard to understand now") Unfortunately, the Python 3 port (aka buildout2) was based in trunk/1.5. I don't understand it either. ;) I spent a few hours yesterday poking at the 2 branch trying to find a way to attack simplifying it. My suspicion is that it would be easier to start from 1.4, although that will require redoing the Python 3 port. As an aside, I'm wrapping up an OS project that I've been working on for the past few months, so I'm ready to spend some focussed time on buildout. > and the 1.5.x trunk itself hasn't seen any > development lately as far as I could see, despite people being stuck on > 1.4.x. So... who's maintaining buildout right now? Theoretically, I am, as are various helpers. Thomas Lotze put in a bunch of work last year trying to help me clean up the 2 branch. I appreciate his efforts, but it wasn't enough.... A little bit was done on the trunk (and ported to the 2 branch) in a sprint last fall. I would love to move to a more team-based approach. I really don't want to be in charge. I certainly don't want to be a blocker. OTOH, someone will beed to protect simplicity, if we ever achieve it. I think to make contributors more effective, we have to simplify the code a lot. (We also need better docs, but that's another issue.) Here's a possible plan: - Create a github repo from svn. Not sure the best apprach to this. I was thinking of using svn2git to copy the zc.buildout svn project. Someone with git foo could help with this, although this wants to be soon. (Like nowish :) - Create a new branch from 1.4.4. (Don't know the proper git terminilogy for this, as I don't know git yet. :) - Remove support for multiple Python interpreters in a single buildout. - Remove setuptools support (just use distribute). - Think of ways to simplify the code, or more importantly, the tests. Maybe provide some test infrastructure to make setup and assertions easier. At this point, I think it should be easier for people to contribute. Then: - Merge reinout-scripts :) - Change some defaults (always unzip, prefer final, etc.) - maybe rename the project to buildout, thus avoiding backward compatibility issues. - Release buildout 0.1 (not zc.buildout). - Port to 2&3 (one codebase as was done for the 2 branch). - Release. - Cherry pick changes since 1.4.4. This would, of course, include better interaction with system Pythons including: - Simple isolation from site customization (ala -S), - Better behavior when not isolated (recognize and don't override system-installed projects), - Better failure. When not isolated and something goes wrong give better error messages. - Work with virtualenv. This needs to be done more simply than what was done in 1.5. (Again, FTR I appreciate the huge effort that went into 1.5.) I have some ideas for this. Releasing along the way. - New hotness (and releases)! - Somewhere along the line, when we think we aren't going to break things for a while, release 1.0. Later - Port to d2/p. Thoughts? Anyone wanna help (take over :)? Wanna maybe sprint via IRC? Jim P.S. I'm happy to let someone else (preferably a team) be in charge, but I have no intention of washing by hands of buildout. -- Jim Fulton http://www.linkedin.com/in/jimfulton From reinout at vanrees.org Sun Mar 25 22:12:30 2012 From: reinout at vanrees.org (Reinout van Rees) Date: Sun, 25 Mar 2012 22:12:30 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On 25-03-12 19:39, Jim Fulton wrote: > On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees wrote: >> Would it be an idea to move zc.buildout out of the zope svn repo into >> github? > > Yes. In fact, I was just looking at that. Github's review mechanism > is particularly attractive. Yep. Comment on entire pull requests, individual commits and individual lines. Works well. (Only real github problem I found is lack of attachments (=screenshots) in issues, but that's not something that ought to bother buildout). > I spent a few hours yesterday poking at the 2 branch trying to find a > way to attack simplifying it. My suspicion is that it would be easier > to start from 1.4, although that will require redoing the Python 3 > port. Perhaps a different way is quicker/easier? What I mean, if buildout is a big hairy complex wrapper around setuptools, perhaps it is easier to build it upon/around/with something else? We know what buildout does and how it does it, so perhaps it is quicker to make it use/wrap distutils2 or virtualenv/pip? Quicker instead of trying to simplify the current code as such? Buildout has some unique niceties like the recipes and a more explicit/solid installation experience than you'd get with virtualenv/pip. ("pip install something" ends up in your system, even when "bin/pip install something" was what you meant). But... is it technically possible to use/wrap virtualenv/pip and let them worry about the upcoming setup.py-to-setup.cfg change, for instance? > I would love to move to a more team-based approach. I really don't > want to be in charge. I certainly don't want to be a blocker. OTOH, > someone will beed to protect simplicity, if we ever achieve it. Well, you're the zope pope, so what about "buildout bishop"? :-) > Here's a possible plan: > > - Create a github repo from svn. > > Not sure the best apprach to this. I was thinking of using svn2git > to copy the zc.buildout svn project. > > Someone with git foo could help with this, although this wants to be > soon. (Like nowish :) svn2git works fine. See http://reinout.vanrees.org/weblog/2011/10/11/moving-svn-to-github.html for some tips and common errors. There are two organizational things that needs to be done: - We need a mapping from zope svn usernames to email addresses (at least for buildout committers). Otherwise all the commits aren't credited (which would be a shame) as github identifies commits by email address. - Where to put it on github? Is there a zope or zope corp or Jim account that's the best place to put it? > - Create a new branch from 1.4.4. > > (Don't know the proper git terminilogy for this, as I don't know git > yet. :) Budget some time for a week of screaming, after that git works fine. > - Remove setuptools support (just use distribute). Or distutils2? Or perhaps even pip? I don't know myself. > Then: > > - Merge reinout-scripts :) With some luck, after using distribute or whatever, the branch won't be needed anymore :-) (Regarding helping: I'll definitively monitor this mailinglist more actively and jump in when possible. I'm however writing a Django book at the moment, so I *do* have time constraints. Note that I've already put a buildout chapter in my table of contents :-) ) Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout at vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" From merwok at netwok.org Sun Mar 25 22:16:51 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 25 Mar 2012 16:16:51 -0400 Subject: [Distutils] packaging docs In-Reply-To: <1332654470.3640.4.camel@thinko> References: <1332654470.3640.4.camel@thinko> Message-ID: <4F6F7D33.2090300@netwok.org> Howdy, > What state are the docs for "packaging" in right now? Let?s go for ?incomplete?. Some of them were updated but not all; I have a patch in progress that I need to finish. Regards From hanno at hannosch.eu Sun Mar 25 22:46:45 2012 From: hanno at hannosch.eu (Hanno Schlichting) Date: Sun, 25 Mar 2012 22:46:45 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On Sun, Mar 25, 2012 at 10:12 PM, Reinout van Rees wrote: > - Where to put it on github? Is there a zope or zope corp or Jim account > that's the best place to put it? I'd suggest the creation of a separate buildout organization. Such a place might over time also get a collection of various recipes, zc.recipe.egg / zc.recipe.cmmi being prime examples. There is a non-sanctioned https://github.com/zopefoundation which I have control of. But as there's really nothing Zope specific about buildout, I wouldn't want to continue associating it with Zope. Hanno From jim at zope.com Sun Mar 25 23:31:13 2012 From: jim at zope.com (Jim Fulton) Date: Sun, 25 Mar 2012 17:31:13 -0400 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On Sun, Mar 25, 2012 at 4:12 PM, Reinout van Rees wrote: > On 25-03-12 19:39, Jim Fulton wrote: >> >> On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees >> wrote: ... >> I spent a few hours yesterday poking at the 2 branch trying to find a >> way to attack simplifying it. My suspicion is that it would be easier >> to start from 1.4, although that will require redoing the Python 3 >> port. > > > Perhaps a different way is quicker/easier? > > What I mean, if buildout is a big hairy complex wrapper around setuptools, > perhaps it is easier to build it upon/around/with something else? > > We know what buildout does and how it does it, so perhaps it is quicker to > make it use/wrap distutils2 Distutils2 has lots of issues. It also lacks things that buildout wants, like, um, eggs... It will become more solid with time, and we can work around it's limitations, but trying to rely on it now wouldn't be a good way to make progress. > or virtualenv/pip? That's both the wrong level of abstraction and an impedence missmatch. > Quicker instead of trying to > simplify the current code as such? I'm pretty hopeful that starting with 1.4 will be sane. > Buildout has some unique niceties like the recipes and a more explicit/solid > installation experience than you'd get with virtualenv/pip. ("pip install > something" ends up in your system, even when "bin/pip install something" was > what you meant). > > But... is it technically possible to use/wrap virtualenv/pip and let them > worry about the upcoming setup.py-to-setup.cfg change, for instance? I really don't think that's a good idea. > >> I would love to move to a more team-based approach. I really don't >> want to be in charge. I certainly don't want to be a blocker. OTOH, >> someone will beed to protect simplicity, if we ever achieve it. > > > Well, you're the zope pope, so what about "buildout bishop"? :-) Seriously, I think that model's broken. What I meant above was that somebody (preferably somebodies) need to protect simplicity. I didn't mean to suggest that it had to be me. >> Here's a possible plan: >> >> - Create a github repo from svn. >> >> Not sure the best apprach to this. I was thinking of using svn2git >> to copy the zc.buildout svn project. >> >> Someone with git foo could help with this, although this wants to be >> soon. (Like nowish :) > > > svn2git works fine. I just made it work on my mac. (An attempt on ubuntu failed for some unknown reason .) I now have a local repo. :) > See > http://reinout.vanrees.org/weblog/2011/10/11/moving-svn-to-github.html > for some tips and common errors. ok... > > There are two organizational things that needs to be done: > > - We need a mapping from zope svn usernames to email addresses (at least for > buildout committers). Otherwise all the commits aren't credited (which would > be a shame) as github identifies commits by email address. Yup, I didn't do that. I can do that I guess. I'll have to chase down the committers emails... > - Where to put it on github? Is there a zope or zope corp or Jim account > that's the best place to put it? I have a personal account. Hanno suggested creating a buildout organization. I'm up with that. Maybe someone can create one and include me. :) >> - Merge reinout-scripts :) > > > With some luck, after using distribute or whatever, the branch won't be > needed anymore :-) distribute is just a setuptools clone. The branch will still be needed. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From hanno at hannosch.eu Sun Mar 25 23:49:07 2012 From: hanno at hannosch.eu (Hanno Schlichting) Date: Sun, 25 Mar 2012 23:49:07 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote: > Hanno suggested creating a buildout organization. ?I'm up with that. > Maybe someone can create one and include me. :) In case you want it, there you go: https://github.com/buildout/buildout Jim is a co-owner of the organization having admin access, the developers team with pull/push rights is currently empty. Hanno From matthew.brett at gmail.com Sun Mar 25 23:58:06 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Sun, 25 Mar 2012 14:58:06 -0700 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: Hi, On Sun, Mar 25, 2012 at 2:49 PM, Hanno Schlichting wrote: > On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote: >> Hanno suggested creating a buildout organization. ?I'm up with that. >> Maybe someone can create one and include me. :) > > In case you want it, there you go: https://github.com/buildout/buildout > > Jim is a co-owner of the organization having admin access, the > developers team with pull/push rights is currently empty. I wrote a little sphinx project that is simple to drop in to your sphinx docs to seed a github workflow: https://github.com/matthew-brett/gitwash http://matthew-brett.github.com/pydagogue/gitwash_build.html Best, Matthew From vincent at nexedi.com Mon Mar 26 10:10:57 2012 From: vincent at nexedi.com (Vincent Pelletier) Date: Mon, 26 Mar 2012 10:10:57 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: <20120326101057.227912e7@vincent-tkpad> Le Sun, 25 Mar 2012 13:39:22 -0400, Jim Fulton a ?crit : > - Create a github repo from svn. > > Not sure the best apprach to this. I was thinking of using svn2git > to copy the zc.buildout svn project. > > Someone with git foo could help with this, although this wants to be > soon. (Like nowish :) FWIW, we (Nexedi) did it internally to include several fixes/changes we need, one branch per fix + merge back to "master" branch (aka trunk in svn terminology), all based on "upstream" branch (which is just buildout's trunk). http://git.erp5.org/gitweb/slapos.buildout.git Each bug-fixing/feature-adding branch is named after the corresponding launchpad bug number. We didn't create branches nor tags corresponding to buildout releases & branches, as far as I can see. We would be happy to help converting the repository - and start hammering it with patches :) . Regards, -- Vincent Pelletier ERP5 - open source ERP/CRM for flexible enterprises From jim at zope.com Mon Mar 26 13:31:08 2012 From: jim at zope.com (Jim Fulton) Date: Mon, 26 Mar 2012 07:31:08 -0400 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On Sun, Mar 25, 2012 at 5:49 PM, Hanno Schlichting wrote: > On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote: >> Hanno suggested creating a buildout organization. ?I'm up with that. >> Maybe someone can create one and include me. :) > > In case you want it, there you go: https://github.com/buildout/buildout > > Jim is a co-owner of the organization having admin access, the > developers team with pull/push rights is currently empty. Thanks! Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From jim at zope.com Mon Mar 26 13:31:31 2012 From: jim at zope.com (Jim Fulton) Date: Mon, 26 Mar 2012 07:31:31 -0400 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: On Sun, Mar 25, 2012 at 5:58 PM, Matthew Brett wrote: > Hi, > > On Sun, Mar 25, 2012 at 2:49 PM, Hanno Schlichting wrote: >> On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton wrote: >>> Hanno suggested creating a buildout organization. ?I'm up with that. >>> Maybe someone can create one and include me. :) >> >> In case you want it, there you go: https://github.com/buildout/buildout >> >> Jim is a co-owner of the organization having admin access, the >> developers team with pull/push rights is currently empty. > > I wrote a little sphinx project that is simple to drop in to your > sphinx docs to seed a github workflow: > > https://github.com/matthew-brett/gitwash > > http://matthew-brett.github.com/pydagogue/gitwash_build.html Thanks, I'll check this out. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From jim at zope.com Mon Mar 26 13:41:14 2012 From: jim at zope.com (Jim Fulton) Date: Mon, 26 Mar 2012 07:41:14 -0400 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: <20120326101057.227912e7@vincent-tkpad> References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> <20120326101057.227912e7@vincent-tkpad> Message-ID: On Mon, Mar 26, 2012 at 4:10 AM, Vincent Pelletier wrote: > Le Sun, 25 Mar 2012 13:39:22 -0400, ... > We would be happy to help converting > the repository - Thanks. So, I guess the first step is to gather git ids for past contributors. :/ I can work on this. I suppose then it's a matter of running svn2git, which I've already done successfully once. Question for everyone interested, do you think I should copy the whole zc.buildout project, and thus its history? Or would it be better to start a new project based on the 1.4 branch (or 1.4.4 tag)? The later would be simpler, as I wouldn't have to chase down (often non-existent) git ids for past contributors. Does anyone have any objections to renaming the project "buildout"? I expect that most existing recipes would work with the new buildout. Recipes that import zc.buildout (zc.buildout.easy_install) would be broken. Those recipes would be likely to be broken by changes we'd make (like omissions of the new 1.5-based APIs) anyway. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From reinout at vanrees.org Mon Mar 26 13:45:22 2012 From: reinout at vanrees.org (Reinout van Rees) Date: Mon, 26 Mar 2012 13:45:22 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> <20120326101057.227912e7@vincent-tkpad> Message-ID: On 26-03-12 13:41, Jim Fulton wrote: > So, I guess the first step is to gather git ids for past > contributors. :/ I can work on this. I suppose then it's a matter of > running svn2git, which I've already done successfully once. OTOH, you don't need absolutely everyone. If you've just got the top 3 you've probably got most of the commits, I'd guess? That's enough. It is just that if you've written 25% of a code base and your commits aren't tied to the account, that's a bit sad. Everyone ought to see that tracking down all emails is OK. So just grab three or four and that's enough. Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout at vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" From reinout at vanrees.org Mon Mar 26 13:46:35 2012 From: reinout at vanrees.org (Reinout van Rees) Date: Mon, 26 Mar 2012 13:46:35 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> <20120326101057.227912e7@vincent-tkpad> Message-ID: On 26-03-12 13:41, Jim Fulton wrote: > Does anyone have any objections to renaming the project "buildout"? > I expect that most existing recipes would work with the new > buildout. Recipes that import zc.buildout (zc.buildout.easy_install) > would be broken. Those recipes would be likely to be broken > by changes we'd make (like omissions of the new 1.5-based > APIs) anyway. Rename is fine with me. And if needed we can mock a zc.buildout inside it to help with moving over, I'd guess. Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout at vanrees.org http://www.nelen-schuurmans.nl/ "If you're not sure what to do, make something. -- Paul Graham" From hanno at hannosch.eu Mon Mar 26 13:54:19 2012 From: hanno at hannosch.eu (Hanno Schlichting) Date: Mon, 26 Mar 2012 13:54:19 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> <20120326101057.227912e7@vincent-tkpad> Message-ID: On Mon, Mar 26, 2012 at 1:46 PM, Reinout van Rees wrote: > On 26-03-12 13:41, Jim Fulton wrote: >> Does anyone have any objections to renaming the project "buildout"? > > Rename is fine with me. +1 But there's about 20 or so packages on PyPi using buildout as a namespace package. That'll work just fine, as long as the new buildout puts the magic into its top level __init__.py and has no other code there. Hanno From cyounkins at gmail.com Sat Mar 24 19:22:39 2012 From: cyounkins at gmail.com (Craig Younkins) Date: Sat, 24 Mar 2012 14:22:39 -0400 Subject: [Distutils] Pass parameter to python interpreter Message-ID: I want to run my code with the -3 flag of the 2.6 interpreter. The proxy script that buildout's zc.recipe.egg:scripts generates does not accept arbitrary interpreter arguments. How can I pass the -3 flag to the proxy script or otherwise run with the -3 flag? Thanks! Craig Younkins -------------- next part -------------- An HTML attachment was scrubbed... URL: From sontek at gmail.com Thu Mar 22 17:46:47 2012 From: sontek at gmail.com (John Anderson) Date: Thu, 22 Mar 2012 11:46:47 -0500 Subject: [Distutils] pip installing to system packages Message-ID: I activate my virtualenv, then try to use pip and it tries to install to the system packages: [koru-sontek.rhcloud.com ~]\> source ~/koru/virtenv/bin/activate (virtenv)[koru-sontek.rhcloud.com ~]\> which pip /var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/bin/pip (virtenv)[koru-sontek.rhcloud.com ~]\> which python /var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/bin/python (virtenv)[koru-sontek.rhcloud.com ~]\> pip install sqlalchemy Downloading/unpacking sqlalchemy Running setup.py egg_info for package sqlalchemy warning: no files found matching '*.jpg' under directory 'doc' no previously-included directories found matching 'doc/build/output' Installing collected packages: sqlalchemy Running setup.py install for sqlalchemy error: could not create '/usr/lib64/python2.6/site-packages/sqlalchemy': Permission denied Complete output from command /usr/bin/python2.6 -c "import setuptools;__file__='/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/build/sqlalchemy/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-xro6j5-record/install-record.txt --install-headers /var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/include/site/python2.6: running install running build running build_py running build_ext running install_lib creating /usr/lib64/python2.6/site-packages/sqlalchemy error: could not create '/usr/lib64/python2.6/site-packages/sqlalchemy': Permission denied ---------------------------------------- Command /usr/bin/python2.6 -c "import setuptools;__file__='/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/build/sqlalchemy/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-xro6j5-record/install-record.txt --install-headers /var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/include/site/python2.6 failed with error code 1 Storing complete log in /var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/.pip/pip.log Traceback (most recent call last): File "/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/bin/pip", line 9, in load_entry_point('pip==1.0.2', 'console_scripts', 'pip')() File "/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/__init__.py", line 116, in main return command.main(initial_args, args[1:], options) File "/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/basecommand.py", line 151, in main log_fp = open_logfile(log_fn, 'w') File "/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/koru/virtenv/lib/python2.6/site-packages/pip-1.0.2-py2.6.egg/pip/basecommand.py", line 177, in open_logfile os.makedirs(dirname) File "/usr/lib64/python2.6/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/var/lib/stickshift/47718763f63148a089bdb31e7ad72d5a/.pip' -------------- next part -------------- An HTML attachment was scrubbed... URL: From marius at pov.lt Mon Mar 26 16:07:00 2012 From: marius at pov.lt (Marius Gedminas) Date: Mon, 26 Mar 2012 17:07:00 +0300 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> Message-ID: <20120326140700.GA20387@fridge.pov.lt> On Sun, Mar 25, 2012 at 10:12:30PM +0200, Reinout van Rees wrote: > On 25-03-12 19:39, Jim Fulton wrote: > >On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees wrote: > >>Would it be an idea to move zc.buildout out of the zope svn repo into > >>github? > > > >Yes. In fact, I was just looking at that. Github's review mechanism > >is particularly attractive. > > Yep. Comment on entire pull requests, individual commits and > individual lines. Works well. (Only real github problem I found is > lack of attachments (=screenshots) in issues, but that's not > something that ought to bother buildout). For the record, screenshots on issues are possible. Here's an example: https://github.com/mgedmin/SnakeMUD/issues/2 The caveat is that you have to upload them somewhere else (e.g. http://imgur.com), and just link to them on GitHub (using Markdown if you want it displayed inline). And, of course, Imgur will delete images if they're rarely accessed, which hasn't happened to me yet, but worries me sometimes. Marius Gedminas -- America and England are two countries separated by a common language. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From jim at zope.com Mon Mar 26 16:38:32 2012 From: jim at zope.com (Jim Fulton) Date: Mon, 26 Mar 2012 10:38:32 -0400 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> <20120326101057.227912e7@vincent-tkpad> Message-ID: On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting wrote: > On Mon, Mar 26, 2012 at 1:46 PM, Reinout van Rees wrote: >> On 26-03-12 13:41, Jim Fulton wrote: >>> Does anyone have any objections to renaming the project "buildout"? >> >> Rename is fine with me. > > +1 > > But there's about 20 or so packages on PyPi using buildout as a > namespace package. Gaaaa. I wasn't aware of that. > That'll work just fine, as long as the new buildout > puts the magic into its top level __init__.py and has no other code > there. No, it won't. You can't count on the order that namespace packages get scanned, so you really can't have code in __init__.py if you want to count on it getting installed. This needs more thought. The new buildout could be a subpackage of the buildout namespace, although that seems awkward. Maybe it would be best to stick with zc.buildout 2.x. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton From hanno at hannosch.eu Mon Mar 26 16:45:28 2012 From: hanno at hannosch.eu (Hanno Schlichting) Date: Mon, 26 Mar 2012 16:45:28 +0200 Subject: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts) In-Reply-To: References: <4B55864E.3080108@simplistix.co.uk> <1099b90b1001190406u52ba46fbs284e1a2a54489de2@mail.gmail.com> <1099b90b1001190816l6af94f67h9074435418034951@mail.gmail.com> <871uohpybv.fsf@transitory.lefae.org> <20120326101057.227912e7@vincent-tkpad> Message-ID: On Mon, Mar 26, 2012 at 4:38 PM, Jim Fulton wrote: > On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting wrote: >> That'll work just fine, as long as the new buildout >> puts the magic into its top level __init__.py and has no other code >> there. > > No, it won't. You can't count on the order that namespace packages get > scanned, so you really can't have code in __init__.py if you want to > count on it getting installed. That's my point. As long as every buildout/__init__.py contains the setuptools namespace code and nothing else, all is fine. So as long as the new buildout distribution does the same, it'll all work. I'm not aware of any problems with having modules directly inside a namespace package. So a buildout/easy_install.py should be importable via "from buildout import easy_install". Hanno From andrea.crotti.0 at gmail.com Mon Mar 26 17:21:22 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Mon, 26 Mar 2012 16:21:22 +0100 Subject: [Distutils] copy binaries in egg Message-ID: <4F708972.9050900@gmail.com> I have custom code to create a nice installer from many Python eggs. The problem is that in these eggs there are many binary files, as for example png or sometimes even dlls (sigh), and they are not declared anywhere in setup.py or Manifest.in. The best solution would be of course to force everyone to include them in setup.py, which would make them part of the package when running egg_info. This is probably not feasible because: - they are too many and everywhere - there is no easy way to detect from the developer if he's including everything, and the only way would be to see the errors on Hudson So the only solution left is to: 1. build with bdist_egg 2. copy inside the build egg all the binaries found any suggestions about how to do that or other ideas? This procedure should normally be run always on the Hudson server, so I can make sure for example that there are no artifacts and the directory tree is always clean.. From andrea.crotti.0 at gmail.com Mon Mar 26 17:39:02 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Mon, 26 Mar 2012 16:39:02 +0100 Subject: [Distutils] copy binaries in egg In-Reply-To: <4F708972.9050900@gmail.com> References: <4F708972.9050900@gmail.com> Message-ID: <4F708D96.7010108@gmail.com> On 03/26/2012 04:21 PM, Andrea Crotti wrote: > I have custom code to create a nice installer from many Python eggs. > > The problem is that in these eggs there are many binary files, as for > example png or sometimes even dlls (sigh), and they are not declared > anywhere in setup.py or Manifest.in. > > The best solution would be of course to force everyone to include them > in setup.py, which would make them part of the package when running > egg_info. > > This is probably not feasible because: > - they are too many and everywhere > - there is no easy way to detect from the developer if he's including > everything, and the only way would be to see the errors on Hudson > > So the only solution left is to: > 1. build with bdist_egg > 2. copy inside the build egg all the binaries found > > any suggestions about how to do that or other ideas? > > This procedure should normally be run always on the Hudson server, so I > can make sure for example that there are no artifacts and the directory > tree is always clean.. Suppose for example I need to include a simple png, apparently I have to do this crazy dance include_package_data=True, packages=find_packages(), package_data={'data': ['xyz.png']}, and even if data/*png is in MANIFEST.in Isn't there a way to let bdist_egg package also everything found through the MANIFEST.in? From pje at telecommunity.com Mon Mar 26 21:22:40 2012 From: pje at telecommunity.com (PJ Eby) Date: Mon, 26 Mar 2012 15:22:40 -0400 Subject: [Distutils] copy binaries in egg In-Reply-To: <4F708D96.7010108@gmail.com> References: <4F708972.9050900@gmail.com> <4F708D96.7010108@gmail.com> Message-ID: On Mon, Mar 26, 2012 at 11:39 AM, Andrea Crotti wrote: > Suppose for example I need to include a simple png, apparently I have to > do this crazy dance > > include_package_data=True, > packages=find_packages(), > package_data={'data': ['xyz.png']}, > > > and even if data/*png is in MANIFEST.in > > Isn't there a way to let bdist_egg package also everything found through > the MANIFEST.in? That's what include_package_data does. You don't need to have both 'include_package_data' and 'package_data={}', because the former is a replacement for the latter that autodetects based on either MANIFEST.in or source control. As long as the file is inside a package and is listed either in the manifest or the source control system, it'll get included. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf at systemexit.de Tue Mar 27 01:18:36 2012 From: ralf at systemexit.de (Ralf Schmitt) Date: Tue, 27 Mar 2012 01:18:36 +0200 Subject: [Distutils] [ANNOUNCE] pypiserver 0.5.2 - minimal pypi server Message-ID: <87aa336jeb.fsf@myhost.localnet> Hi, I've just uploaded pypiserver 0.5.2 to the python package index. pypiserver is a minimal PyPI compatible server. It can be used to serve a set of packages and eggs to easy_install or pip. pypiserver is easy to install (i.e. just easy_install pypiserver). It doesn't have any external dependencies. http://pypi.python.org/pypi/pypiserver/ should contain enough information to easily get you started running your own PyPI server in a few minutes. The code is available on github: https://github.com/schmir/pypiserver Changes in version 0.5.2 ------------------------- - provide a way to get the WSGI app - improved package name and version guessing - use case insensitive matching when removing archive suffixes - fix pytz issue #6 -- Cheers, Ralf From robhealey1 at gmail.com Tue Mar 27 01:36:07 2012 From: robhealey1 at gmail.com (Rob Healey) Date: Mon, 26 Mar 2012 16:36:07 -0700 Subject: [Distutils] HELP NEEDED NOW!!! Message-ID: Greetings: I am sorry for being presumptuous to impose myself upon the list here, but I am frustrated and needing help before I can continue.... I have DistUtils2 1.0a4 installed already, but this is my first time trying to use it... >From this documentation list here [1], it says to use: from distutils2.core import setup then when I try to run: $ python setup.py build it says that there is no module named core ??? Is this documentation outdated or am I doing something wrong? Please help quickly..... [1] http://packages.python.org/Distutils2/distutils/examples.html -- Sincerely yours, Rob G. Healey -------------- next part -------------- An HTML attachment was scrubbed... URL: From merwok at netwok.org Tue Mar 27 05:35:10 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Mon, 26 Mar 2012 23:35:10 -0400 Subject: [Distutils] Distutils2 documentation nonworking In-Reply-To: References: Message-ID: <4F71356E.40903@netwok.org> Hello, Le 26/03/2012 19:36, Rob Healey a ?crit : > I am sorry for being presumptuous to impose myself upon the list > here, but I am frustrated and needing help before I can continue I understand your frustration, but I think nonetheless that it?s not the best attitude one can have when addressing a mailing list where people volunteer help. Why apologize for something when you can just avoid doing the thing? :) By the way I hope you have seen the warning that distutils2 is not ready for use in critical situations yet. > I have DistUtils2 1.0a4 installed already, but this is my first time > trying to use it... The documentation lives at http://docs.python.org/dev/packaging (just replace packaging with distutils2 in your imports and the rest of the code is the same). It is however incomplete, as you?ve found out, and I am sorry for this. You?re the second person to report this to the mailing list in a few days (see http://mail.python.org/pipermail/distutils-sig/2012-March/018381.html). I am working on a huge doc patch, but in the meantime here are the instructions for getting started: - write a setup.cfg file following the rules described in the document http://docs.python.org/dev/packaging/setupcfg - replace every ?python setup.py x? you see in the docs with ?pysetup run x? - see ?pysetup --help? and ?pysetup run --help? Hope this helps, Regards From robhealey1 at gmail.com Tue Mar 27 06:34:14 2012 From: robhealey1 at gmail.com (Rob Healey) Date: Mon, 26 Mar 2012 21:34:14 -0700 Subject: [Distutils] problem with python file??? Message-ID: Greetings: I have a file [1], that I am having a problem with, and I do not understand why? Could you please explain how to handle this please??? [1] '/home/Frog/geps0042/gramps/plugins/records.gpr.py' error: package directory '/home/Frog/geps0042/gramps/plugins/records/gpr' does not exist -- Sincerely yours, Rob G. Healey -------------- next part -------------- An HTML attachment was scrubbed... URL: From robhealey1 at gmail.com Tue Mar 27 06:40:09 2012 From: robhealey1 at gmail.com (Rob Healey) Date: Mon, 26 Mar 2012 21:40:09 -0700 Subject: [Distutils] version conflicts??? Message-ID: Hello: Could someone explain why the difference in the two versions? If DistUtils2 is the new improved, why does it have a lower version numbers??? >>> import distutils >>> distutils.__version__ '2.7.2' >>> import distutils2 >>> distutils2.__version__ '1.0a3' Thank you for your help... -- Sincerely yours, Rob G. Healey -------------- next part -------------- An HTML attachment was scrubbed... URL: From regebro at gmail.com Tue Mar 27 11:07:16 2012 From: regebro at gmail.com (Lennart Regebro) Date: Tue, 27 Mar 2012 11:07:16 +0200 Subject: [Distutils] version conflicts??? In-Reply-To: References: Message-ID: On Tue, Mar 27, 2012 at 06:40, Rob Healey wrote: > Hello: > > Could someone explain why the difference in the two versions?? If DistUtils2 > is the new improved, why does it have a lower version numbers??? It's called distutils2 to clarify that it is a new module. Why would not the versioning restart from 1.0? They are not compatible, this is the new way of distributing. It's a replacement, but not a drop in replacement. //Lennart From benji at benjiyork.com Tue Mar 27 12:34:33 2012 From: benji at benjiyork.com (Benji York) Date: Tue, 27 Mar 2012 06:34:33 -0400 Subject: [Distutils] problem with python file??? In-Reply-To: References: Message-ID: On Tue, Mar 27, 2012 at 12:34 AM, Rob Healey wrote: > Greetings: > > I have a file [1], that I am having a problem with, and I do not understand > why?? Could you please explain how to handle this please??? > > [1] '/home/Frog/geps0042/gramps/plugins/records.gpr.py' > > error: package directory '/home/Frog/geps0042/gramps/plugins/records/gpr' > does not exist Modules can not have a dot in their name. To make foo.bar.baz importable you need a foo directory with a baz subdirectory that contains a file named baz.py. See http://docs.python.org/tutorial/modules.html#packages for all the details. Also, despite the name of this list, a more appropriate place to ask this kind of question would be the python-list or tutor list: http://www.python.org/community/lists/ -- Benji York From chris at python.org Tue Mar 27 12:31:46 2012 From: chris at python.org (Chris Withers) Date: Tue, 27 Mar 2012 11:31:46 +0100 Subject: [Distutils] HELP NEEDED NOW!!! In-Reply-To: References: Message-ID: <4F719712.10608@python.org> On 27/03/2012 00:36, Rob Healey wrote: > Is this documentation outdated or am I doing something wrong? Please > help quickly..... Why? Suggest you read: http://www.catb.org/~esr/faqs/smart-questions.html#urgent Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From ronaldoussoren at mac.com Tue Mar 27 15:01:09 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 27 Mar 2012 15:01:09 +0200 Subject: [Distutils] RFC: Binary Distribution Format for distutils2/packaging In-Reply-To: References: <4F60076F.1080103@oddbird.net> Message-ID: On 14 Mar, 2012, at 18:42, Chris Barker wrote: > > > Universal binaries (i.e. more than one architecture in one binary) > have never been properly supported by binary eggs/setuptools. I think > it may be as simple as the naming convention -- the binary would be > named according to the machine it was built on (i.e. PPC) but when you > tried to install in on another machine, setuptools would look for one > called, i.e. "x86" and not find it. There may be some other issues, > too, but in any case, we need to make sure the naming convention > handles the multi-architecture case as well. Could you eleborate on that? Distutils supports fat binaries just fine, and AFAIK setuptools and distribute inherit that support. There were some problems in earlier python versions, especially in the Apple provided installs in OSX 10.4, but those issues have been resolved years ago. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4788 bytes Desc: not available URL: From andrea.crotti.0 at gmail.com Tue Mar 27 18:29:52 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Tue, 27 Mar 2012 17:29:52 +0100 Subject: [Distutils] copy binaries in egg In-Reply-To: References: <4F708972.9050900@gmail.com> <4F708D96.7010108@gmail.com> Message-ID: <4F71EB00.9080608@gmail.com> On 03/26/2012 08:22 PM, PJ Eby wrote: > On Mon, Mar 26, 2012 at 11:39 AM, Andrea Crotti > > wrote: > > Suppose for example I need to include a simple png, apparently I > have to do this crazy dance > > include_package_data=True, > packages=find_packages(), > package_data={'data': ['xyz.png']}, > > > and even if data/*png is in MANIFEST.in > > Isn't there a way to let bdist_egg package also everything found > through the MANIFEST.in? > > > That's what include_package_data does. You don't need to have both > 'include_package_data' and 'package_data={}', because the former is a > replacement for the latter that autodetects based on either > MANIFEST.in or source control. As long as the file is inside a > package and is listed either in the manifest or the source control > system, it'll get included. > Great thanks for the answer, I missed that bit.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robhealey1 at gmail.com Wed Mar 28 03:05:21 2012 From: robhealey1 at gmail.com (Rob Healey) Date: Tue, 27 Mar 2012 18:05:21 -0700 Subject: [Distutils] help needed please... Message-ID: Greetings: I am providing a pastebin link so that you may see my code without having to download anything... http://paste.pocoo.org/show/572324/ I am receiving this error, and I was wondering if you could tell me what might be wrong? [Frog at PouncingAliens geps0042]$ python setup.py build running build running build_py Traceback (most recent call last): File "setup.py", line 117, in setup(**cfg_to_args()) File "/usr/lib64/python2.7/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/distutils/command/build_py.py", line 93, in run self.build_packages() File "/usr/lib64/python2.7/distutils/command/build_py.py", line 372, in build_packages self.build_module(module, module_file, package) File "/usr/lib64/python2.7/distutils/command/build_py.py", line 333, in build_module "'package' must be a string (dot-separated), list, or tuple") TypeError: 'package' must be a string (dot-separated), list, or tuple -- Sincerely yours, Rob G. Healey -------------- next part -------------- An HTML attachment was scrubbed... URL: From regebro at gmail.com Wed Mar 28 12:04:29 2012 From: regebro at gmail.com (Lennart Regebro) Date: Wed, 28 Mar 2012 12:04:29 +0200 Subject: [Distutils] help needed please... In-Reply-To: References: Message-ID: On Wed, Mar 28, 2012 at 03:05, Rob Healey wrote: > Greetings: > > I am providing a pastebin link so that you may see my code without having to > download anything... > > http://paste.pocoo.org/show/572324/ Huh? > ??? "'package' must be a string (dot-separated), list, or tuple") > TypeError: 'package' must be a string (dot-separated), list, or tuple Well, is it? //Lennart From andrea.crotti.0 at gmail.com Wed Mar 28 18:41:56 2012 From: andrea.crotti.0 at gmail.com (Andrea Crotti) Date: Wed, 28 Mar 2012 17:41:56 +0100 Subject: [Distutils] bdist_egg and pyo files Message-ID: <4F733F54.5010508@gmail.com> I've been asked to ship our eggs as pyo files instead of pyc, but 1. I'm not 100% sure it's a good idea, what issues can this raise? 2. I can't find any option in bdist_egg to actually compile the files in optimized mode, is it not there on purpose?? Thanks, Andrea From pje at telecommunity.com Wed Mar 28 21:56:24 2012 From: pje at telecommunity.com (PJ Eby) Date: Wed, 28 Mar 2012 15:56:24 -0400 Subject: [Distutils] bdist_egg and pyo files In-Reply-To: <4F733F54.5010508@gmail.com> References: <4F733F54.5010508@gmail.com> Message-ID: On Wed, Mar 28, 2012 at 12:41 PM, Andrea Crotti wrote: > I've been asked to ship our eggs as pyo files instead of pyc, but > 1. I'm not 100% sure it's a good idea, what issues can this raise? > 2. I can't find any option in bdist_egg to actually compile the files > in optimized mode, is it not there on purpose?? > > You have to do "setup.py build_py -O1 bdist_egg" (or -O2 if you prefer). Doing this will include the .pyo files *in addition* to the .pyc files. There is currently no way to disable the .pyc files from being included. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merwok at netwok.org Thu Mar 29 05:28:48 2012 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 28 Mar 2012 23:28:48 -0400 Subject: [Distutils] bdist_egg and pyo files In-Reply-To: References: <4F733F54.5010508@gmail.com> Message-ID: <4F73D6F0.50000@netwok.org> Le 28/03/2012 15:56, PJ Eby a ?crit : > On Wed, Mar 28, 2012 at 12:41 PM, Andrea Crotti > wrote: >> I've been asked to ship our eggs as pyo files instead of pyc, but >> 1. I'm not 100% sure it's a good idea, what issues can this raise? - assert statements will not be executed; if some code uses asserts to do argument checking, behavior can change for the worse. - the global name __debug__ will be False; in the stdlib for example it?s used by imaplib to log additional info (the assumption being that in production it would be run with -O). I?m not sure -O is really useful. >> 2. I can't find any option in bdist_egg to actually compile the files >> in optimized mode, is it not there on purpose?? >> You have to do "setup.py build_py -O1 bdist_egg" (or -O2 if you prefer). > Doing this will include the .pyo files *in addition* to the .pyc files. Only because --compile is the default; passing ?--no-compile -01? will disable pyc and enable pyo. Regards From sandro at e-den.it Sat Mar 31 20:48:23 2012 From: sandro at e-den.it (Alessandro Dentella) Date: Sat, 31 Mar 2012 20:48:23 +0200 Subject: [Distutils] Buildout & develop-eggs troubles Message-ID: <20120331184823.GA25740@ubuntu> Hi, I'm trying buildout but I'm having a hard time trying to understand the logic of develop-egg. I tested both mr.developer recepy and gp.csvdevelop and I stumbled on the same problem, so I guess I'm misunderstanding something. I want to add a development repository named jumbo-core that contains several 1^ level packages (and a correct setup.py), one of which is 'jumbo', I get to the point that: 1. source is added to ./dev/jumbo-core 2. an egg-link is added to develop-eggs/jumbo-core.egg-link pointing to the correct path where the hg repository is checked out, but that path is not added to the sys.path. My configuration is as follows:: [buildout] develop = . parts = python scripts test ipython extensions = gp.vcsdevelop develop-dir = ./dev vcs-extend-develop = hg+${thunder:jumbonew}/jumbo-core#egg=jumbo-core [python] recipe = zc.recipe.egg interpreter = python eggs = lunar Adding 'jumbo' to eggs directive raises the error: "Couldn't find index page for 'jumbo' (maybe misspelled?)" If I add dev/jumbo-core to develop option I get the message:: Skipping 'hg+/misc/src/hg/thunder/jumbo-new/jumbo-core#egg=jumbo-core'. Package is already in the develop option but dev/jumbo-core is not added to the sys.path. Any hint is appreciated. TIA sandro *:-) -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy From jim at zope.com Sat Mar 31 22:12:10 2012 From: jim at zope.com (Jim Fulton) Date: Sat, 31 Mar 2012 16:12:10 -0400 Subject: [Distutils] Buildout & develop-eggs troubles In-Reply-To: <20120331184823.GA25740@ubuntu> References: <20120331184823.GA25740@ubuntu> Message-ID: On Sat, Mar 31, 2012 at 2:48 PM, Alessandro Dentella wrote: > > > Hi, > > I'm trying buildout but I'm having a hard time trying to understand the > logic of develop-egg. > > I tested both mr.developer recepy and gp.csvdevelop and I stumbled on the > same problem, so I guess I'm misunderstanding something. > > I want to add a development repository named jumbo-core that contains > several 1^ level packages (and a correct setup.py), one of which is 'jumbo', > I get to the point that: I don't understand alot of what you said above, but hopefully, I can get by. :) > > ?1. source is added to ./dev/jumbo-core > > ?2. an egg-link is added to develop-eggs/jumbo-core.egg-link pointing to > ? ? the correct path where the hg repository is checked out, but that path > ? ? is not added to the sys.path. My configuration is as follows:: > > ? ? ?[buildout] > ? ? ?develop = . > ? ? ?parts = python scripts test ipython > ? ? ?extensions = gp.vcsdevelop > ? ? ?develop-dir = ./dev > ? ? ?vcs-extend-develop = hg+${thunder:jumbonew}/jumbo-core#egg=jumbo-core > > ? ? ?[python] > ? ? ?recipe = zc.recipe.egg > ? ? ?interpreter = python > ? ? ?eggs = lunar > > Adding 'jumbo' to eggs directive raises the error: "Couldn't find index page > for 'jumbo' (maybe misspelled?)" > > If I add dev/jumbo-core to develop option I get the message:: > > ?Skipping 'hg+/misc/src/hg/thunder/jumbo-new/jumbo-core#egg=jumbo-core'. Package is already in the develop option > > but dev/jumbo-core is not added to the sys.path. > > Any hint is appreciated. The develop option names a (or many) setup.py file. You can also, as a common shortcut, name a directory containing setup.py file. The develop option invokes the setup.py file to create a develop egg. The setup.py file defines a product name. From the name of the egg link you mention, I'm guessing that the setup.py file in the current directory ('.') sets the project name to 'jumbo-core'. The egg recipe builds a script based on a list of requirements as listed in the eggs option. (Yeah, 'requirements' would have been a better name...) The requirements are typically just project names, although they can also contain version specifications. If, as I suspect, the project name is 'jumbo-core', rather than 'jumbo', then you need to add jumbo-core to your eggs option (on a separate line). Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton