Mailman 3 April 2006 - Distutils-SIG

Re: [Distutils] setuptools, PYTHONPATH and suExec
by Phillip J. Eby April 26, 2006

April 26, 2006

At 03:39 PM 4/26/2006 -0400, Joe Gregorio wrote: >The problem seems to be PYTHONPATH, or the lack-there-of. >I have a PYTHONPATH in my shell and that seems to >be the reason paste works from the shell. In the .CGI script >I don't have PYTHONPATH and the import of paste fails. > >I tried manipulating sys.path at runtime from within the CGI, >but I believe that is too late >and by the time my script starts running the wrong (non- >PYTHONPATH) site.py has already been read. ... >Is there a way to get this to work or am I out of luck? Try this: #!/bin/sh """:" PYTHONPATH=whatever exec /path/to/python $0 ${1+"$@"} """ The trick here is that Python sees those three lines as a triple-quoted docstring, but the shell sees the first line as a no-op, and then bails out after the 'exec', so it doesn't read the rest of the file. The ${} magic is shell quoting stuff to make sure that all arguments are properly escaped; I don't pretend to understand how it works. :)

1 0

Internal documentation for egg formats now available
by Phillip J. Eby April 25, 2006

April 25, 2006

To satisfy requests on Python-Dev, I've just added some internal "developer's" documentation to setuptools. You don't need to read it unless you are working on setuptools itself, want to assist in troubleshooting a problem with your installation, or want to understand how setuptools may affect your packaging of libraries that use it (i.e., you're building RPMs or debs or what-have-you for packages that use setuptools, or any Python 2.5 package). The docs can be found at http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt (source text), or http://peak.telecommunity.com/DevCenter/EggFormats (HTML-formatted version). Included are summary descriptions of the formats of all of the standard metadata produced by setuptools, along with pointers to the existing manuals that describe the syntax used for representing requirements, entry points, etc. as text. The .egg, .egg-info, and .egg-link formats and layouts are also specified, along with the filename syntax used to embed project/version/Python version/platform metadata. Last, but not least, there are detailed explanations of how resources (such as C extensions) are extracted on-the-fly and cached, how C extensions get imported from zipfiles, and how EasyInstall works around the limitations of Python's default sys.path initialization. Please remember, however, that a lot of this stuff is purely internal details and subject to change. Most of the information is also available to you directly via the "pkg_resources" API, so you probably don't care about the actual file formats in such cases anyway.

1 0

Problem importing pylirc egg
by Philippe Normand April 24, 2006

April 24, 2006

Hi, i've easy_installed pylirc from sourceforge as an Egg. It's correctly compiled/installed on my system. But i can't import it, though it's found by pkg_resources: >>> import pylirc Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named pylirc >>> import pkg_resources >>> pkg_resources.require('pylirc') [pylirc 0.0.5 (/home/phil/lib/python2.4/pylirc-0.0.5-py2.4-linux-i686.egg)] What am i supposed to do with that Requirement object so as to get pylirc module in my namespace ? Philippe

3 9

Re: [Distutils] Upgrading eggs from custom url
by Phillip J. Eby April 21, 2006

April 21, 2006

At 07:47 AM 4/21/2006 -0400, Charlie Moad wrote: >On 4/20/06, bear <bear42(a)code-bear.com> wrote: > > > > Charlie Moad wrote: > > > When issuing an "--upgrade" option, can the "download_url" be checked > > > automatically, or is there an existing way I can get a handle on that > > > "download_url" variable to pass to easy_install? Any advice would be > > > appreciated. > > > > > Check out the --find-links option: > > > > easy_install -f http://some_url eggname > > > > http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options > >I know I can pass that, but it is a matter of introspecting an >installed egg to find its download_url. Eggs don't carry download URLs, they only carry dependency links, and only if the author specified them. If what you're saying is that you want to be able to check the page you originally got the egg from for updates, there isn't currently any way to do that, except to effectively maintain your own package index. It would probably be a better idea to gently encourage the package's author to run "setup.py register" on a regular basis to keep their PyPI listing up-to-date, since that helps everybody else, too.

1 0

Upgrading eggs from custom url
by Charlie Moad April 21, 2006

April 21, 2006

I am using setuptools to maintain some plugins I wrote for a python based protein viewer. I would like to have another plugin that simply checks for updates for the currently installed plugins. Code may help, so basically I would like to run: from setuptools.command import easy_install easy_install.main('-U MyPlugin'.split()) This would work fine if I registered my plugins on Pypi, but just trust me that I shouldn't be pushing this junk up there yet. I saw the "dependency_links" option, and that is close to what I want. However, I would also like easy_install to check for an update to "MyPlugin" there as well. When issuing an "--upgrade" option, can the "download_url" be checked automatically, or is there an existing way I can get a handle on that "download_url" variable to pass to easy_install? Any advice would be appreciated. Thanks, Charlie

2 2

setuptools and site.py
by Ian Bicking April 19, 2006

April 19, 2006

I'm trying to resolve a few issues in working-env.py (http://svn.colorstudy.com/home/ianb/working-env.py) and I'm running into some conflicts with setuptools. working-env.py basically works by creating another site.py, which doesn't add site-packages and other directories that I don't care for. Without setuptools this works pretty well. But because of changes in setuptools, added right around the time I wrote working-env.py, setuptools now wants to write its own site.py and doesn't like mine. One option is to integrate setuptools' changes into my own customized site.py, and then add __boot to the top to fake setuptools out. I think that would be bothersome. Another option would be if setuptools looked for something ahead of site. Like, say, siteoverride. Then I could put my siteoverride in place instead of site.py, let setuptools have site.py, and avoid the system site.py entirely. Also, and this is related to a request Jim made a while ago, I'm monkeypatching setuptools currently to change the way it creates scripts, and it would be nice if this wasn't necessary. Or was easier. The monkeypatch is basically changing the script generated so that it sets sys.path before importing site. Here's what I'm doing (in setuptools/__init__): import setuptools.command.easy_install as easy_install def get_script_header(script_text, executable=easy_install.sys_executable): from distutils.command.build_scripts import first_line_re first, rest = (script_text+'\n').split('\n',1) match = first_line_re.match(first) options = '' if match: script_text = rest options = match.group(1) or '' if options: options = ' '+options if options.find('-S') == -1: options += ' -S' shbang = "#!%(executable)s%(options)s\n" % locals() shbang += ("import sys, os\n" "join, dirname = os.path.join, os.path.dirname\n" "lib_dir = join(dirname(dirname(__file__)), 'lib', 'python%s.%s' % tuple(sys.version_info[:2]))\n" "sys.path.insert(0, lib_dir)\n" "import site\n") return shbang easy_install.get_script_header = get_script_header -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

Further extending of setup.py
by Ian Bicking April 19, 2006

April 19, 2006

I'd like to get rid of the "paster" script, moving some of what it does into setup.py or elsewhere. To a degree that is possible, but I think requires some additions to setuptools: * An entry point group that is not globally looked up, like distutils.commands. This would be a set of commands the package provides only for itself. I expect it to look like: [distutils.commands.local] sql_record = sqlobject.manage.distextension:sql_record Exactly like what we have currently, just not looked up globally. * Additionally, or probably even better, something that enumerates locations for commands. E.g.: extra_commands=['SQLObject'] And then it would look in the SQLObject egg for distutils.commands.local, and apply everything found there to this package. Right now, for instance, buildutils adds a "pytest" command to every project, even though it only applies to some projects (for some commands this is ok, like "info", so two different entry points makes sense). A project could list itself to provide its own custom commands; I think that won't be too circular. Typically commands you provide for yourself or someone else are different -- e.g., the SQLObject commands don't apply to SQLObject itself. * Everything that can be done on a deployed egg will probably go in app/egg-specific command-line scripts, and maybe I'll make a little framework to make these easier to write, but that's entirely an implementation detail. But I'm also thinking that extra_commands could be used as a hint to that framework, and would kind of facilitate coordination of in-development commands with after-deployment commands. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 5

setuptools now in Python 2.5 trunk
by Phillip J. Eby April 18, 2006

April 18, 2006

Just a heads-up: setuptools 0.7a1.dev-r45519 is now in the Python 2.5 stdlib trunk. The docs haven't been converted yet, nor have the various PEPs and NEWS or whatsnew docs been updated. But it's in, and the tests run as part of the Python 2.5 regression test suite. I had to tweak a few things in setuptools 0.7 in order to make everything work cleanly across 2.3, 2.4, and 2.5, but it's done now. And, as a side benefit, setuptools 0.7 now installs its own fixes for the pydoc and doctest problems with modules in zipfiles! (And Python 2.5 doesn't have those problems to begin with; it also supports showing tracebacks and warnings and other things using source code pulled from .egg or .zip files.) These fixes are automatically substituted for the corresponding 2.3 and 2.4 stdlib modules whenever you install setuptools 0.7 with an older Python version, unless you are installing setuptools as a system package. (That's because system packages installed to site-packages can't override stdlib modules, but .eggs installed anywhere (even site-packages) *can*.) So, if you get a chance to try the curren SVN head of Python, or the 2.5 alpha 2 release, let me know if you encounter any issues with setuptools. Also, if you're using the setuptools 0.7 trunk with any other Python version, please let me know about any issues there as well. Thanks. (By the way, in setuptools 0.7 I've reinstated support for running with "python -m easy_install", because that was easier than trying to get the Python build process to install a script or executable.)

1 0

Howto include .dll files and .so files
by vijayendra bapte April 18, 2006

April 18, 2006

Hi All, I have created one package. It contains few binary files such as .so and .dll files. I want to include those files in my package distribution. I tried adding those files using data files but it was not working. Can any one please guide me how to include those files in my distribution. Regards, Victor

1 0

setuptools 0.6 beta branch created - trunk is 0.7 alpha
by Phillip J. Eby April 14, 2006

April 14, 2006

I've just created a SVN branch for setuptools 0.6 beta and beyond, which can now be accessed with 'setuptools=dev06'. 'setuptools==dev' now refers to the 0.7 development trunk. I had to do this now because there's a fair amount of surgery I need to do to make setuptools merge with the Python 2.5 standard library, including module moves, renames, etc. So, to not lose all the hard-won stability of 0.6 as it is, I've split things up. Naturally, I hope that 0.7 will be just as stable as 0.6; it's more of a "have something always ready to release" issue. There's going to be some fairly intense reshufflings of the source code, though, including a switch from reStructuredText to PythonDoc LaTeX for the documentation, due to the need for integration with the Python documentation system. The C source code for the launcher will get moved, etc. There is also going to be some code migrated from pkg_resources to the stdlib's "pkgutil" module - specifically, the importer-specific infrastructure for filesystem and zipfile packages, as it's already been duplicated two other places in the stdlib. So the plan is to consolidate the various versions of this into pkgutil. setuptools 0.7 will include a replacement version of pkgutil for use by version of Python <2.5, but the setuptools bundled with Python 2.5 will just use the stdlib pkgutil. I don't plan to make any API changes to pkg_resources, however. It's only some of the implementation that's moving. It's also likely that Python 2.5 and up will use 'python -m easy_install' as the default way to invoke easy_install, but the older versions will retain their separate easy_install executable. I'll keep you posted here if there are any changes to the above. Please keep in mind that if you are currently relying on 'setuptools==dev' being relatively stable, you should consider whether you want to start using 'setuptools==dev06' instead, at least until an actual 0.7a1 release is available. In the meantime, I'm assuming that all is going well with 0.6a11, and that it can reasonably be bumped to 0.6b1 sometime next month. Please let me know if there are any issues outstanding with the 0.6 versions. Thanks.

1 0