Mailman 3 November 2005 - Distutils-SIG

Re: [Distutils] formencode as .egg in Debian ??
by Kurt Schwehr Nov. 24, 2005

Nov. 24, 2005

As a person who works as a packager with a debian based distribution (fink on Mac OSX) I am glad to see this discussion. I have no personal opinion about python eggs, but would really like to find a way to get some nice packages into the system and have been totally unable to figure out how to deal with eggs. I see the point of allowing developers to have multiple versions of packages when testing, but we definitely want to avoid that in the actual fink tree at all costs. It would be great to have a build system that can switch between what we need as stable distribution packagers and what people want/need in their local trees. My hope is that eggs in the long run can help the packagers track dependencies, but still let the packagers handle those dependencies. -kurt http://schwehr.org/blog

1 0

Re: [Distutils] formencode as .egg in Debian ??
by Phillip J. Eby Nov. 24, 2005

Nov. 24, 2005

At 11:17 PM 11/23/2005 +0000, Paul Moore wrote: >OK, I see it now. I need to reread your previous posts about the 3 >layouts, as understanding those would probably give me the remaining >pieces of the puzzle that I need. To summarize, the layouts are .egg file (1) or directory (2), which both have a projectname-version-pyversion-platform.egg filename, and contain the project contents alongside an EGG-INFO subdirectory where the metadata lives. The third layout, originally designed for development rather than deployment, is just the project contents in an arbitrary directory, alongside a projectname.egg-info directory with the metadata in it. In setuptools 0.6a9, I will modify pkg_resources so that the .egg-info directory can also be a file (whose contents are ignored, for now) and so that its filename can also include the version, so that the PKG-INFO file can be optional in that case. This will make it easier for people wrapping non-setuptools packages as system-packaged eggs, because they will just need to "touch site-packages/projectname-version.egg-info" in order to let setuptools-using projects know that the project has been installed. In a sense, this approach sounds like a kind of "PEP 262 lite", in that it produces a basic database of installed packages, just as the .egg layout can be thought of as "PEP 262 plus", in that it offers extensible metadata as well as basic presence-and-version information. >Regarding me being the only person interested in Windows installers >which wrap eggs (which I don't dispute), Oh, I doubt you're really the only person *interested*, you're just the only person who's *asked* for it. :) > I'd be curious to know what >proportion of TurboGears (or any other egg-based project, I guess) >users are on Windows. And of them, how many have it in "live" use (as >how I'd be willing to install on a development box would differ from >what I'd do - or possibly be allowed to do - on a production box). Beats me; in my personal case, the intersection of "Windows" and "production box" is the empty set. :) >One final point - I think that naming of setup.py commands may be >confusing things here. Before eggs, the main bdist_ commands >(bdist_wininst, bdist_rpm, bdist_deb, bdist_msi, ...) created *system >packages* by your definition above. And yet, bdist_egg doesn't - it >creates an egg, which is a subtype of a project distribution. This >leads (IMO) to confusion, in that we are now seeing interest in system >packages which wrap eggs. That's a reasonable thought, except for bdist_dumb, which I think was already an exception to your otherwise-reasonable theory. > Arguably, there should ultimately be >distutils commands for this. But what to call them? bdist_egg_wininst, >bdist_egg_deb, etc? Something else? Actually, I think the better long-term approach is more likely to be tools like easy_deb that wrap easy_install. "Better" here meaning that it can save the system packager work, because it can handle finding and fetching and building in an automated way even for non-setuptools packages it has never seen before. While there are occasionally some issues with projects that have unusual customizations to the distutils, those customizations would potentially give a system packager similar troubles anyway. Conversely, if you tried to build system-packaged eggs for non-setuptools packages without easy_install, you'd have to patch their setup scripts in order to get at those hypothetical bdist_egg_foo commands. Last, but not least, system packagers vary widely in their essential build process, so it's probably easier and less fragile to let them wrap easy_install and then work from one of the three egg layouts, than to try to embed the packaging process entirely within the distutils. Of course, I haven't played around with anything but bdist_wininst and bdist_rpm, but it seems to me that at least bdist_rpm suffers from a lot of complexity by having to squeeze the process into the scope of a single distutils command, versus what it would be like if you just took an egg and turned it into an RPM. >This probably just proves that naming isn't my strong suit :-) But do >you see my point that bdist_egg is the odd one out among the bdist_ >commands (as it doesn't create a system package)? Yeah, except for the part where bdist_dumb isn't really a system packager. I always interpreted bdist as simply meaning a "binary" or "built" distribution; i.e., one that does not require a build step, just "installation".

2 1

Re: [Distutils] formencode as .egg in Debian ??
by Phillip J. Eby Nov. 23, 2005

Nov. 23, 2005

At 04:53 PM 11/23/2005 +0000, Paul Moore wrote: >Interesting. I would say that *something* in the >easy_install/egg/setuptools area feels *exactly* like CPAN to me. >Where I would like to use my system's standard packaging solution (I'm >on Windows, so I mean the Windows Add/Remove Programs control panel >applet here, as supported by bdist_wininst or more recently >bdist_msi), I am being required to use a different mechanism. Right, but this is an issue on a different metalevel. Nobody is proposing that Debian users install eggs directly into their /usr/lib/python2.x/site-packages directory. >Like David, I don't like anything other than the "official" (ie, >Windows installers in my case) mechanisms having access to the Python >installation directory. > >If there was a way of building a Windows installer that installed >packages in "egg" form, so I didn't have to use setup.py at all when >installing, just double-click on the installer, that would suit me. >This feels like what the Debian people want with their .deb format as >well. Right - this would hopefully be covered at some point using an .msi or .exe wrapper for eggs on Windows. So far, though, you're the only person I've heard from about wanting this on Windows, versus the number of people who want it for e.g. Debian. So I'm still considering Debian wrapper support as being more urgent than .msi wrapper support. My point to David was simply that egg packaging in the .egg form is more akin to Stow than to CPAN, so most of the flaws of CPAN are not applicable to them. >The wording I'm using here is possibly not accurate - there seem to be >a confusing mix of concepts and ideas going round, with no-one having >a good understanding of all of them. My apologies - if there's a good >glossary somewhere, which explains what to call things like > > * The executable I click on in Windows to install something > * The .deb file that a Debian user downloads and installs I would call these "system packages", to distinguish them from Python packages. You (and others) would like to ensure that any project you install is wrapped in a system package. > * The set of files that end up in Python's site-packages A "project distribution", or just a "project" (which is a less accurate term but more convenient). > - for a "normal" install (bdist_wininst, non-egg, whatever) This has never seemed to me to need a special term unto itself, so I don't have one. > - for an egg An egg. :) > - that comprises the difference between the above two ( :-) ) Egg metadata. An egg is just an installed project distribution that includes egg metadata, in one of the three possible layouts for putting that metadata alongside the rest of the project contents.

3 3

Setuptools now in FreeBSD Ports Collection
by Wolfgang Langner Nov. 23, 2005

Nov. 23, 2005

Hello, yesterday I discovered that setuptools are now in the FreeBSD ports collection: http://www.freshports.org/devel/py-setuptools/ (official ports index) http://www.freebsd.org/cgi/ports.cgi?query=setuptools&stype=all bye by Wolfgang

1 0

Version numbers with a letter at the end
by Ben Bangert Nov. 22, 2005

Nov. 22, 2005

Does setuptools distinguish and recognize letters in a version? For example, the latest Myghty is: version='0.99a' When I up it to '0.99a.1', and setuptools does a pre-requisite check, it doesn't seem to recognize that 0.99a.1 is more recent than 0.99a. Also, this seems like it would cause problems with requirements that look for a dev version, as it'd be: "Myghty >= 0.99.adev-r1980" Is a numerical-only version number a requirement for version info under setuptools? - Ben

2 1

HTTP auth in svn repositories
by Ben Bangert Nov. 22, 2005

Nov. 22, 2005

A svn repository I was attempting to install from has a public login/ group, so I tried entering the egg link like so: http://guest:guest@svn.myghty.org/myghty/branches/ 99a_exception_save#egg.... However the parsing setuptools did resulted in the following error: httplib.InvalidURL: nonnumeric port: 'guest(a)svn.myghty.org' I thought using that http format was fairly standard for putting http basic auth, shouldn't setuptools honor it? Thanks, Ben

2 1

Finding only activated eggs in Environment()
by Rob Cakebread Nov. 22, 2005

Nov. 22, 2005

Hi, I'm using pkg_resources.Environment() to get a list of all eggs. Besides making a list of activated eggs with pkg_resources.working_set and comparing it with pkg_resources.Environment, is there a way to check if an individual egg is activated? Has the setuptools cvs repository moved to svn with Python? I've found the API docs on cvs.sf.net, but it seems a couple versions behind. Thanks, Rob -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B

3 4

Recent upgrade uses security restrictions?
by Ben Bangert Nov. 22, 2005

Nov. 22, 2005

I ran the setuptools upgrade of Kid to 0.7.1 this morning with no problems. When I ran it just now using the latest setuptools, I get this error which I've never seen before: Best match: kid 0.7.1 Downloading http://lesscode.org/dist/kid/0.7.1/kid-0.7.1.tar.gz Processing kid-0.7.1.tar.gz Running kid-0.7.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install- RBM6QG/kid-0.7.1/egg-dist-tmp-egfsVX error: SandboxViolation: mkdir('/Users/ben/.python-eggs', 511) {} The package setup script has attempted to modify files on your system that are not within the EasyInstall build area, and has been aborted. This package cannot be safely installed by EasyInstall, and may not support alternate installation locations even if you run its setup script by hand. Please inform the package's author and the EasyInstall maintainers to find out if a fix or workaround is available. Is this a new restriction that kicked in? Thanks, Ben

2 1

Overiding the site-packages/<module> directory name?
by Bob Tanner Nov. 22, 2005

Nov. 22, 2005

Is there a way to override the site-packages/<module> directory name? I'm trying to make a debian package for FormEncode-0.4, by default "/usr/bin/python2.4 setup.py install --no-compile -O0" creates a directory structure llike: `-- usr |-- lib | `-- python2.4 | `-- site-packages | `-- FormEncode-0.4-py2.4.egg | |-- EGG-INFO | `-- formencode | |-- javascript | `-- util Reading python-policy 1.4, I believe a 3rd party module should be just /usr/lib/python<X>.<Y>/site-packages/<module-dir> I would like to see `-- usr |-- lib | `-- python2.4 | `-- site-packages | `-- formencode | |-- javascript | `-- util I'm working around the "problem" by installing a formencode.pth pointing to the /usr/lib/python2.4/site-packages/FormEncode-0.4-py2.4.egg directory. I've played around with FormEncode's setup.py and the site-packages path seems to be based on the setup(name=xxx, version=yyy), but I could not see any way to change these values without really messing up all the other tools that depend on these values. -- Bob Tanner <tanner(a)real-time.com> | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288

4 6

setuptools, eager_resources, and DLLs
by Gerhard Häring Nov. 21, 2005

Nov. 21, 2005

Hello, I want to make pysqlite installable as an egg. The normal pysqlite install works like this (win32): pysqlite2/__init__.py pysqlite2/_sqlite.pyd pysqlite2/sqlite3.dll I read that with eager_resources, setuptools can install shared libraries too. But I have no idea how to use this feature if the extension module is located in a package. Any ideas? -- Gerhard

2 1