Distutils-SIG September 2010

distutils-sig@python.org

30 participants
49 discussions

by Chris Withers

Hi All, File "virtualenv-1.5\virtualenv.py", line 1645, in <module> main() File "virtualenv-1.5\virtualenv.py", line 556, in main prompt=options.prompt) File "virtualenv-1.5\virtualenv.py", line 645, in create_environment site_packages=site_packages, clear=clear)) File "virtualenv-1.5\virtualenv.py", line 769, in install_python copy_required_modules(home_dir) File "virtualenv-1.5\virtualenv.py", line 723, in copy_required_modules dst_filename = change_prefix(filename, dst_prefix) File "virtualenv-1.5\virtualenv.py", line 704, in change_prefix assert relpath[0] == '/' AssertionError Looks like a classic non-cross-platform piece of code, right? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

11 years

whats the best way to depend on tools needed for setup.py/setup metadata

by Ronny Pfannschmidt

Hi, i'd like to support turning my guess version from hg metadata tool into a setup dependency and thus kill the need to ship a python file. Currently i just import it + call a function, but that doesn't exactly work if the module is missing and a dependency. Is there any way to turn it into some sort of plugin/extension that automatically gets installed/used to get that metadata. regards Ronny

11 years

[ANN] setuptools post install script for bdist_wininst

by Manlio Perillo

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Following the suggestion to use a post installation script in order to install dependencies for a package installed using bdist_wininst, I wrote this reusable script: http://paste.pocoo.org/show/260644/ In order to use it, the script must be declared as a script in the setup.py file. In order to ensure setuptools is installed, the same should be do with the ez_setup bootstrap script. The ez_post_install script will do: 1) Get the installed project name by parsing the bdist_wininst file name 2) Make sure setuptools is installed (if ez_setup is available) 3) Install all dependencies of the installed package, using easy_install 4) Optionally add shortcuts of all gui scripts in the Start Menu\Programs\<project name> special folder 5) Optionally add shortcuts of all gui scripts in the Desktop Problems ======== Since the post install script may take some time downloading and installing packages, the UI of the Windows installer is frozen, without giving user any feedback. This is a problem with the installer, since stdout and stderr are fully buffered. TODO ==== In case a dependency have extension code that must compiled, in 99% of the cases the post install script will fail, since the compiler or some library is not available. This should not happen; the post install script should, instead, check if in the package download_url there is a bdist_wininst executable, download it and execute it. Suggestions are welcome. Manlio Perillo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyLlWAACgkQscQJ24LbaURBJwCgkU87bIiGGt2uj3qBcxZ1NIS6 07AAn2mXk9kQvtjgEXtWb3uwiQT69mwZ =l8M2 -----END PGP SIGNATURE-----

11 years

[issue115] setup.py = Invalid Syntax

by Will

New submission from Will <william.full.moon(a)gmail.com>: I installed Python v3.1.2. I brought Easy_install via the instructions using CURL and setup.py. When I wanted to use easy_install to get pySQLite ... ** c:\bin\python\v3\scripts\easy_install.exe -v pysqlite The install fails. With a syntax error. One diagnostic asked for Sphinx. So I instituted the Sphinx down load. With the same result (see attached log and error file). There seems to be a fundamental problem in the Easy_install script, viz: File "c:\bin\python\v3\lib\site-packages\distribute-0.6.14-py3.1.egg \setuptools\sandbox.py", line 32, in <lambda> ).read(), "setup.py", 'exec'), File "setup.py", line 80 print "Is sphinx installed? If not, try 'sudo easy_install sphinx'." ^ I've tried to capture the error and stdout in the attached log file. Cheers, Will ---------- files: sqlite.log messages: 546 nosy: aplatypus priority: critical status: unread title: setup.py = Invalid Syntax Added file: http://bugs.python.org/setuptools/file71/sqlite.log _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue115> _______________________________________________

11 years

Re: [Distutils] bdist_wininst and dependencies with setuptools

by P.J. Eby

At 11:46 PM 9/9/2010 +0200, Manlio Perillo wrote: >Il 09/09/2010 23:03, P.J. Eby ha scritto: > > At 07:37 PM 9/9/2010 +0200, Manlio Perillo wrote: > >> I would like to avoid having to create an all in one installer using > >> pyinstalled; is this possible? > > > > No; bdist_wininst doesn't support dependencies. > >Is this hard to implement? Well, you'd need to write some C code, or else implement something in a Python post-install script. I'm not sure how difficult that would be, but it's more effort than I'd personally like to put in. >What about distutils2? I don't know if they're working on that. > > If you need Windows > > users to install dependencies, they'll have to use easy_install. (I'd > > say "or pip", but pip doesn't support installing pre-built binaries.) > > > >Using easy_install still requires the user to open the command prompt, >locate where the easy_install.exe is installed, and run it. > >This is what I would like to avoid. Then py2exe or some other sort of installer is probably your best bet.

11 years

please fix easy_install shorter URL preference (Was: easy_install wrong download site preference)

by anatoly techtonik

Hello Phillip, Again, I've run into completely irrational 'easy_install' behavior that prefers to download from shorter URLs instead of PyPI ones if the same filename exists in both places. `protobuf` project and `gerald` are not installable due to this behavior. http://code.google.com/p/protobuf/issues/detail?id=66 https://sourceforge.net/apps/trac/halfcooked/ticket/29 Gerald is the second package from the last 4 months that I couldn't install due to this very obscure behavior, and I suspect there are more. Phillip, could you, please, still run through your archives to success in explaining why this logic of choosing a shorter download URL is necessary? I'd really to see what packages benefit from it, because I believe Google protocol buffers popularity alone is enough to change the behavior. Thanks. -- anatoly t. On Fri, Jul 2, 2010 at 5:06 AM, P.J. Eby <pje(a)telecommunity.com> wrote: > At 01:33 AM 7/2/2010 +0300, anatoly techtonik wrote: >> >> On Fri, Jul 2, 2010 at 12:10 AM, P.J. Eby <pje(a)telecommunity.com> wrote: >> >> > >> >> > It prefers newer packages, or, if the versions are the same, it >> >> > prefers >> >> > the shortest download URL. Ã‚ In this case, the Google Code url is >> >> > shorter. >> >> >> >> That's illogical. Better prefer PyPI if versions are the same. >> > >> > The "shortest path" logic is there to avoid certain file recognition >> > problems that occur without it. Â The special case of PyPI isn't special >> > enough to break those rules. >> >> Although practicality beats purity. Can you list those "certain file >> recognition problems"? I.e. Explicit is better than implicit. > > I have a vague recollection that it was Fredrik Lundh's website that sparked > the original realization of the need for preferring shorter URLs, but I > wouldn't swear to it. I'd have to dig through years of revision history to > find the original change, assuming I documented it well enough. The choice > of short paths over long was also intended to favor nearby files over > further ones, and local paths over URLs. > > (All that being said, it's still fundamentally a heuristic, and not a very > good one at that. But that doesn't automatically make any other heuristic > *better*; this is one area where status quo bias is a good thing.) > > >> That's why it should use the site where all filenames are Python >> downloads if filenames are the same. > > And how would that work with all the PyPI clones, private indexes, etc.? > > >> > No. Â You'd need to remove the current "home_page" setting, or point it >> > elsewhere. >> >> That's very strange. Then what download_url is for? > > The home page and download URLs are simply treated as pages which may > contain links to files, if they are not themselves links to files. That's > the only special status they have. > > >> >> Â (I understand that people do not want to touch setuptools code >> >> anymore) >> > >> > That's not really the issue; the issue here is that package precedence >> > is >> > based on a stable comparison scheme, where it doesn't make sense to give >> > one >> > location priority over another, as it will simply lead to someone else >> > complaining about the changed behavior, because they were relying on a >> > different URL having precedence under the current scheme. >> >> These rules need to be described first. What if somebody already broke >> the proper order and now everybody suffers? If autodiscovery rules >> were well described - it was possible to analyse them and propose more >> intuitive approach. Then if "someone else" will attempt to complain - >> you could send them to the PEP or another "how and why" document. > > http://peak.telecommunity.com/DevCenter/setuptools#making-your-package-avai… > > http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api > > >> I thought it will raise the weight of those links if there could be a >> rel="download" attribute. > > There is no "weighting" of links - what is weighted are distributions, and > distribution objects only have their raw URL available as a basis for > sorting once the version and archive type (the two higher-precedence > attributes) are considered. The place where a URL was retrieved from is not > tracked, and thus can't be used for sorting without a good chunk of > refactoring... which refactoring would likely break tools that build on top > of setuptools' PackageIndex class. > > In short, what you're asking for is a pretty major feature that would be > difficult to implement in a way that would be guaranteed not to break other > things. > >

11 years

Buildout release news

by Gary Poster

I intend to release zc.buildout 1.5.0 Monday, August 23. I will merge the code from from svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix into trunk. This will change the bootstrap.py script on which some people depend via svn externals. Also, existing bootstrap and buildout invocations that do not specify a particular buildout release will automatically get the new release, as usual. In light of the troubles with the 1.5.0b1 release, particularly for users of virtualenv, I have done four things. 1. I added an automated test for the virtualenv interaction problem encountered in the last release, and fixed it. If you are using virtualenv, it now uses the old behavior for generating scripts. I and others have had success manually testing virtualenv + buildout with with these changes. 2. Today I released zc.buildout 1.4.4 (http://pypi.python.org/pypi/zc.buildout/1.4.4). The 1.4.4 release is a release for people who encounter trouble with the 1.5 line. By switching to the associated bootstrap script (http://svn.zope.org/repos/main/zc.buildout/branches/1.4/bootstrap/bootstrap…) you can stay on 1.4.4 until you are ready to migrate. 3. I have a new help document describing the changes in the 1.5 line. This will be part of the documentation shown on pypi. You can see it here: http://svn.zope.org/zc.buildout/branches/gary-betafix/SYSTEM_PYTHON_HELP.tx… 4. For the future, the new (1.5) versions of Buildout and the bootstrap script now prefer final versions of Buildout, recipes, and extensions. This can be changed by using the --accept-buildout-test-releases flag (or -t for short) when calling bootstrap. This will hopefully allow beta releases of these items to be more easily and safely made in the future. The change log is here: http://svn.zope.org/zc.buildout/branches/gary-betafix/CHANGES.txt?view=mark… Gary

11 years

equivalent of --tag-svn-revision for mercurial?

by Chris Withers

Hi All, Is there any equivalent of --tag-svn-revision for Mercurial? cheers, Chris

11 years

bdist_wininst and dependencies with setuptools

by Manlio Perillo

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Today I was building a package that must be installed on a Windows system (I'm on Linux). I simply did: python setup.py bdist_inst and I was expecting that, when executed on the Windows machine, it would not only install my package, but also all dependencies declared in the setup file. This was not the case. I would like to avoid having to create an all in one installer using pyinstalled; is this possible? Note that dependencies are all pure Python modules available on pypi, except PyQt (that is installed using the installer provided by riverbank). Thanks Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJG1gACgkQscQJ24LbaUTcCgCfRFOCF101mhRfaWCuU+5g41Wj X2EAn2tOiYudntVi06aa9L9IdpNxp5y2 =YiSl -----END PGP SIGNATURE-----

11 years

problem with sdist for nested packages

by Doug Hellmann

I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories. The full list of files is fairly long, but here's a snippet to give you an idea of the layout for the inputs: PyMOTW/xml PyMOTW/xml/__init__.py PyMOTW/xml/etree PyMOTW/xml/etree/__init__.py PyMOTW/xml/etree/ElementTree PyMOTW/xml/etree/ElementTree/__init__.py PyMOTW/xml/etree/ElementTree/ElementTree_create.py PyMOTW/xml/etree/ElementTree/... When I build the sdist, I get: build/lib/PyMOTW/xml build/lib/PyMOTW/xml/etree build/lib/PyMOTW/xml/etree/ElementTree build/lib/PyMOTW/xml/etree/ElementTree/__init__.py build/lib/PyMOTW/xml/etree/ElementTree/ElementTree_create.py build/lib/PyMOTW/xml/etree/ElementTree/... The __init__.py at the "xml" and "xml/etree" levels are not included. As a result, the sdist won't install because it wants to populate a PyMOTW.ElementTree package but the directory doesn't exist. I also tried adding other .py files at those levels in the directory structure (in case an "empty" directory was being ignored), but that had no effect. The traceback I get trying to install the sdist is: Traceback (most recent call last): File "setup.py", line 7, in <module> paver.tasks.main() File "paver-minilib.zip/paver/tasks.py", line 621, in main File "paver-minilib.zip/paver/tasks.py", line 604, in _launch_pavement File "paver-minilib.zip/paver/tasks.py", line 569, in _process_commands File "paver-minilib.zip/paver/setuputils.py", line 146, in __call__ File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/install.py", line 71, in run _install.run(self) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/install.py", line 563, in run self.run_command('build') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build.py", line 127, in run self.run_command(cmd_name) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/build_py.py", line 77, in run self.build_packages() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 366, in build_packages modules = self.find_package_modules(package, package_dir) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 218, in find_package_modules self.check_package(package, package_dir) File "/Users/dhellmann/.virtualenvs/pymotwtest/lib/python2.7/site-packages/distribute-0.6.10-py2.7.egg/setuptools/command/build_py.py", line 192, in check_package init_py = _build_py.check_package(self, package, package_dir) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/build_py.py", line 191, in check_package "package directory '%s' does not exist" % package_dir) distutils.errors.DistutilsFileError: package directory 'PyMOTW/ElementTree' does not exist Has anyone seen this problem before? Thanks, Doug

11 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG September 2010