Mailman 3 July 2009 - Distutils-SIG

Single version number
by Marius Gedminas 11 Jul '09

11 Jul '09

What do people use to avoid repeating the version number both in the setup.py as well as in application/library code, when the application/library wants to know its own version number? I've seen several options: 1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py do from yourpackage import __version__ and pass that to setup() 2) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py execfile(os.path.join(os.path.dirname(__file__), 'src', 'yourpackage', '__init__.py'), d), then use d['__version__'] 3) put a file called version.txt in yourpackage/, have setup.py read it, make sure it's included in MANIFEST.in 4) I don't recall actually ever seeing this one, but it should be possible to use pkg_resources to query the version of yourpackage (downside: if you're running from a source checkout without installing, you won't get the right version number) Marius Gedminas -- In order to get a loan you must first prove you don't need it.

10 14

Re: [Distutils] [Python-Dev] PEP 376 - Open questions
by Paul Moore 09 Jul '09

09 Jul '09

2009/7/9 Tarek Ziadé <ziade.tarek(a)gmail.com>: > On Thu, Jul 9, 2009 at 3:42 AM, Sridhar > Ratnakumar<SridharR(a)activestate.com> wrote: >> Other than easy_install/pip, there is also PyPM which is being developed at >> ActiveState. PyPM is the Python package manager much like what ppm is for >> ActivePerl. >> > > Great ! besides the RECORD file, anything remark on the PEP from a > PyPM point of view ? > Once Paul has finished to work on the PEP 302 part of the prototype, > maybe we could try it out > on PyPM to see how it fits ? Note: the "pkgutil2" implementation I pushed to Tarek's bitbucket repository a day or so ago includes PEP 302 support (using a few new finder methods, as proposed). It's ready to go now. It's as compliant with the PEP as possible given the outstanding questions (I've implemented some things on the basis of what I thought was consensus here, even though the PEP has not changed yet to reflect that - using "metadata" rather than "egginfo" in method names, and removing the local= parameter from some of the methods, being the 2 I can recall immediately). I'd like to add a test case using a non-standard PEP 302 importer, but that's a small detail. There are bound to be holes in the implementation, especially around the areas of the open questions that started this thread. I'd appreciate feedback, but I'm not expecting to make code changes until the PEP is changed - it's too much like trying to hit a moving target at the moment! Paul. PS I've added distutils-sig back into the cc list. Please keep "PEP 376" in the subject of any subsequent threads on that list if you want my input, as I don't follow all the traffic on there.

1 1

easy_install MySQL_python error
by Christian Brodbeck 08 Jul '09

08 Jul '09

Hi there, I am trying to install MySQL_python, but I get the following error: "EnvironmentError: mysql_config not found" (complete terminal readout below). I am using python 2.5 and the latest version of os X on a macbook. I could not find anything in the mailinglist archive (using google's site: search - is there a better way to search it?) and easy_install page advises to write to this mailinglist if there are problems, so I was wondering if anyone could help. Thanks, Christian Christian$ sudo easy_install-2.5 MySQL_python Password: Searching for MySQL-python Reading http://pypi.python.org/simple/MySQL_python/ Reading http://sourceforge.net/projects/mysql-python Best match: MySQL-python 1.2.3c1 Downloading http://osdn.dl.sourceforge.net/sourceforge/mysql-python/MySQL-python-1.2.3c… Processing MySQL-python-1.2.3c1.tar.gz Running MySQL-python-1.2.3c1/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-xtH6un/MySQL-python-1.2.3c1/egg-dist-tmp-8rW4eF sh: mysql_config: command not found Traceback (most recent call last): File "/opt/local/bin/easy_install-2.5", line 8, in <module> load_entry_point('setuptools==0.6c9', 'console_scripts', 'easy_install-2.5')() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 1671, in main File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 1659, in with_ei_usage File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 1675, in <lambda> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/distutils/core.py", line 151, in setup dist.run_commands() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/distutils/dist.py", line 986, in run_commands self.run_command(cmd) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/distutils/dist.py", line 1006, in run_command cmd_obj.run() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 211, in run File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 446, in easy_install File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 476, in install_item File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 655, in install_eggs File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 930, in build_and_install File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/easy_install.py", line 919, in run_setup File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/ sandbox.py", line 27, in run_setup File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/ sandbox.py", line 63, in run File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg/setuptools/ sandbox.py", line 29, in <lambda> File "setup.py", line 15, in <module> setup(name="pbrain", File "/tmp/easy_install-xtH6un/MySQL-python-1.2.3c1/ setup_posix.py", line 43, in get_config File "/tmp/easy_install-xtH6un/MySQL-python-1.2.3c1/ setup_posix.py", line 24, in mysql_config EnvironmentError: mysql_config not found

3 3

Re: [Distutils] setuptools inquiry
by P.J. Eby 07 Jul '09

07 Jul '09

At 01:05 PM 7/7/2009 -0400, Joseph Armbruster wrote: >I am interested in creating the windows .exe installer but could not >find any materials for doing so in the repo. Is there someplace >else I should be looking? python setup.py bdist_wininst

2 1

windows installer questions
by Joseph Armbruster 07 Jul '09

07 Jul '09

All, Who builds the setuptools .exe installer that is available via pypi.python.org? Is the source for the installer published somewhere (nsis/.msi/etc..)? I'm interested in building an installer for this myself and would like to obtain the installer source if possible. In addition, there are two binaries that are part of the source tree, cli.exe and gui.exe. Where can the source for these utilities be found? I checked the svn longs and could not find a hint as to where they came from. Thank You in advance, Joseph Armbruster

1 0

setuptools inquiry
by Joseph Armbruster 07 Jul '09

07 Jul '09

Phillip, I just downloaded setuptools from: http://svn.python.org/projects/sandbox/trunk/setuptools I am interested in creating the windows .exe installer but could not find any materials for doing so in the repo. Is there someplace else I should be looking? In addition, there are two binary utilities, cli.exe and gui.exe that are distributed with the tool. Is the source for these utilities stored somewhere on svn.python.org? Thank You in advance, Joseph Armbruster

1 0

Python package distribution standards
by Ben Finney 07 Jul '09

07 Jul '09

Howdy all, I'm cross-posting between the Python distutils discussion forum and the Freedesktop distributions discussion forum. If you think any OS-specific discussion forums need to be involved, please ask a representative to join one or more of these forums so the discussion doesn't get too attenuated. For a number of weeks now, the Python package distribution standards have been undergoing intensive scrutiny in the wake of much face-to-face discussion at Pycon 2009. Many goals are being juggled in an attempt to get a beneficial result for everyone affected by these standards. The discussion has reached a point of some “open questions” <URL:http://article.gmane.org/gmane.comp.python.devel/105237> on the current draft of PEP 376 <URL:http://www.python.org/dev/peps/pep-0376/>, which has re-raised the issue of how Python distribution standards could be improved with regard to OS distribution packaging requirements. I've made a case for metadata that would be beneficial to OS packagers <URL:http://thread.gmane.org/gmane.comp.python.devel/105237/focus=105270>, but I am not very cognizant of the needs of specific OS packaging systems. We need input from others who know and care about how Python packages should fit into specific operating system package management systems. If you feel you have constructive input on how Python's package distribution metadata can be improved for the needs of OS packagers (along with other needs being targeted by such metadata), please read the standards drafts, join this discussion, and weigh in now while the topic is hot. -- \ “The industrial system is profoundly dependent on commercial | `\ television and could not exist in its present form without it.” | _o__) —John Kenneth Galbraith, _The New Industrial State_, 1967 | Ben Finney

2 1

RFC PEP 386 : Version comparisons
by Tarek Ziadé 07 Jul '09

07 Jul '09

Hello back to that discussion, after re-reading all the threads I have a proposal : 1- let's add as we said "install_requires" in PEP 345 and describe in it that people can define requirements, but without giving them rules for the version schemes. We will just write in that PEP that it's up to the *dependency manager* (pip, setuptools, zc.buildout, etc) to provide a cmp() for the version. The only rule will be that each dependency is described like this : dist_name [<|>|==|!=|>=|<=] version where version is free and dist_name in [a-zA-Z0-9] 2- let's drop PEP 386 completely 3- I'll start a separate, standalone project that contains the less controversial form of verlib.py, (the one that doesn't contains the post-dev stuff) so we won't lose the work we all did in that. Any thoughts ? Tarek

5 17

Where is the setuptools source repository?
by Chris Withers 07 Jul '09

07 Jul '09

Hi All, I'm trying to figure out why my package_data is being ignored. Of course, setuptools ends up being an egg, so it's impossible to pdb through. So, I thought I'd checkout the setuptools trunk and just use that instead. But where is it? The closest I could find is: http://svn.python.org/projects/sandbox/trunk/setuptools ...but this has no tags, branches, etc. So is this it? If not, where is it? cheers, Chris

6 19

[buildout] path usage and proposal
by Jim Fulton 07 Jul '09

07 Jul '09

For buildout, there are a number of use cases relevant to using system Python: U1 Use a system Python with all of the goodies and changes it provides. This works now if a buildout is bootstrapped with a system Python. U2 Use a system python w/o 3rd-party additions. U3 Use a system python w/o 3rd-party additions but cherry-pick some 3rd-part additions. Note that this is especially attractive on system (like ubuntu) that make 3rd-party packages available in separate locations. Right now, buildout deals with path in a somewhat ad-hoc manner. There are two paths: - The install path, which normally includes develop-eggs and eggs. It may also include the buildout and setuptools distribution locations. - The system path. Buildout searches the install path for distributions that are already installed. The intent is to skip searching external sources if a distribution is already installed. Unfortunately, buildout unwittingly searches sys.path for installable packages. This is because indexes take a search_path argument that specifies a path to search for installed distribtions. This defaults to sys.path and buildout doesn't pass it. This means that buildout mistakingly searches sys.path when looking for new packages. This, of course, is silly. Paths are also used by running scripts to search for packages. When buildout generates a script, it generates a search path based on the working set. Note that it adds the working set locations to the base path that the script starts with. For existing behavior, we can work smarter by searching the base path + the current install paths for installed distribution and passing an empty search path the index used to look for uninstalled distributions. Note that not every distribution found on the base path is importable. In particular, an egg may be found on the base path, but the egg itself must be added to the Python path to be importable. The base path is used for 2 things: - A place to look for installed distributions - A place to import things from at run time. It would be cleaner to separate these uses, although, for usability, it might be simpler to keep them together. There's probably little harm in including a path in sys.path that *only* includes eggs. So hear's a proposal: 1. Add an include-site-packages option, defaulting to true. If false: set the base path to those paths not added by running site.py. We'll get this by evaling the output of: python -Sc "import sys; print (repr(sys.path))" The base path will be used for searching for distrbutions *and* for computing the run-time path. The script preamble will become someting like:: sys.path[:] = ... # set sys.path to the base path for path in ...: # iterate over working set using expression we use now if path not in sys.path: sys.path.insert(0, path) Note: a. We completely replace sys.path b. If a distro's location was already in the base path, we don't insert it. This will help avoid accidently putting a base path ahead of egg-supplied paths. 2. Add a search-path option. By default, it will be the base path. It can be manipulated in 2 ways: - It can be set. If this is done, the base path will be ignored. - It can be incremented, for example, to cherry-pick the foo package on ubuntu: search-path += /usr/share/pycentral/foo/site-packages So, in summary, we already handle U1. Proposal 1 addresses U2. Proposal 1 and 2 together addresses U3. Note that proposal 2 would also make it easier to share prebuilt eggs with clean Pythons. So, for example, if you already have an lxml egg built for a clean Python, you could add it to the search path to use it in a buildout. Thoughts? Questions? Jim -- Jim Fulton Zope Corporation

2 2