Re: [Distutils] formencode as .egg in Debian ??
--Phillip == Phillip J Eby [EMAIL PROTECTED] writes: (btw Phillip, thanks muchly for your patience with this thread) Phillip If you unpack this as-is, but rename EGG-INFO to Phillip foobar.egg-info (today) or foobar-1.2.egg-info (when I Phillip release 0.6a9 of setuptools), and the whole tree above is in Phillip a directory on sys.path, this egg is good to go. Ok. Phillip I would like to clarify the phrase shipped as an egg, Phillip though. To me, that would mean that the developer is Phillip distributing a binary .egg file, and I'm assuming that Debian Phillip is primarily interested in *source* packages, being a Free Phillip Software distribution. Debian ships both source packages and binary packages. It's my impression (although I could be wrong) that most users use only the binary packages. Phillip (A binary .egg doesn't have to contain source code at all; Phillip you can specifically build it with the source stripped if you Phillip desire.) Normal Debian Python (binary) packages include .py files, which are compiled to both .pyc and .pyo as part of their installation, but C extensions are shipped as pre-built .so libraries. Phillip While I don't advocate changing all Debian Python packages to Phillip add this metadata, I do suggest it's a practical way to deal Phillip with certain dependency issues. Assume a developer grabs some setuptools-using Python app, and tries to run it on a Debian system. It will look in sys.path for its dependencies. If it doesn't find the egg info, as I understand it, the app will then go out and grab those dependencies via PyPI until it's able to run. But, if compatible versions of those dependencies are already installed as Debian packages *without* egg metadata, will these be ignored? Even if it was possible for Debian to extend this downloading mechanism so that it looked for dependencies via apt-get before trying to install from the raw source or egg or whatever, it would usually be the case that the user running the newly downloaded Python application would not have permission to install system packages. Ultimately, I suppose this isn't a major problem -- if a user (or developer) runs such an application, they might end up pulling down and installing a bunch of dependencies in their home directory (that's where they'd go by default, right?) But once the app is packaged, both it and its dependencies will be available for all users, so it'll just be early adopters who will encounter this. d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Distutils] formencode as .egg in Debian ??
--Phillip == Phillip J Eby [EMAIL PROTECTED] writes: Phillip Python developers would *love* to have Debian manage their Phillip packages, they would simply like to be able to verify at Phillip runtime that the management has in fact been done. It's not Phillip that we don't trust you, it's just that we're paranoid. :) From a Debian perspective, that's strictly your own affair. Debian packages just work, and if they don't it's a bug. There's no need for anyone other than the packager to worry about this. Of course, the application is free to do its own verification of this, but it would need to use an internal mechanism: since there's no *need* for it, Debian doesn't expose this information from its internal dependency database. Phillip We'd like for Debian to advertise to our packages, precisely Phillip what versions of which of our dependencies are installed. In general, I don't see why packages should care. Either it works, in which case there's no problem, or it doesn't, in which case it's a packaging bug, and it will be fixed. Of course, when supporting packages fail to provide a stable API, this means you end up needing to install multiple versions, or have the application adapt internally. Supporting the installation and simultaneous use of multiple versions seems to be a goal of eggs? FWIW, that's kinda heretical on Unix (which might explain some of the antipathy). Phillip We'd also like for Debian to include the metadata we provided Phillip with our packages, when it installs them. It think that's a reasonable expectation. So long as Python packages are location-agnostic, and allow Debian to put such things where it thinks is reasonable? Phillip And we'd like all this to cleanly work with any Phillip locally-installed non-Debian eggs that might be in the mix, Phillip since we need to do development, beta testing, etc. And non-egg packages as well, right? But again, I don't see why that would be a problem. Perhaps it's worth pointing out: Debian users typically don't recognise dependency management as a problem, because it's not a problem for them. If you can't apt-get something, the choice is to wait a month for it to arrive in unstable, or to enter a world of pain where you're dealing with other (often conflicting) dependency management systems or no dependency management at all (and btw, this is the commonality I think eggs have with CPAN and PEAR). Debian developers take their role of banishing this problem seriously, which I suppose is why this is a contentious topic. d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Distutils] formencode as .egg in Debian ??
--Paul == Paul Moore [EMAIL PROTECTED] writes: 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. Paul Sorry, I don't know what Stow is, so that doesn't clarify things Paul to me (but that's OK, I got your point from the previous Paul paragraph, so if the clarification helps David, that's enough). In fact, I use stow for anything not supported by Debian. Stow allows you to maintain a repository of built installations, and to activate overlapping things one at a time. Normally, this means different versions of the one product. It achieves this by managing symlink farms. It's a fairly Unix-y thing :-) 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. Paul Gotcha. And you understand my position perfectly. That's my wish also. I realise that other people (possibly more so on non-Debian systems?) don't have such an attachment to the way the system manages installed products. Don't get me wrong: I'm not disputing that .eggs are useful, nor that they provide capabilities that a Debian-packaged result of an installation using 'python setup.py install' might not (at least now, easy-deb aside). And, fwiw, as a developer of Python modules, a way of distributing them that allows others to safely and easily install different versions of my modules with different applications on the same machine is attractive. But I was hoping that I could help clarify the point of view of a Debian user, by pointing out that there's at least some part of the Debian user community that won't like installing .egg applications unless they're sanely converted to .debs d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Distutils] formencode as .egg in Debian ??
--Phillip == Phillip J Eby [EMAIL PROTECTED] writes: Phillip This is a major advantage over developers who do not do this, Phillip not only in developer effectivness, but also because a Phillip developer who depends exclusively on a specific packaging Phillip system will not have the same effective reach for their Phillip offering, or conversely will require a greater investment of Phillip effort to support various packaging systems. coming to this a little late So, this would seem to imply that installation of eggs is similar to using PEAR or CPAN? If so, from the perspective of a Debian user, this is a major disadvantage. I'm used to having a single framework that manages my packages and their dependency relationships, and it works well. Adding a language-specific mechanism simply causes problems, with stray files installed into directories owned by a .deb package, versions of CPAN/PEAR-installed packages drifting out of date with the interpreter and standard library, and just the cognitive load of needing to deal with something other than apt-get. My experiences with CPAN/PEAR packages have been universally bad, and I now try very, very hard to use nothing except apt/dpkg. I understand that from a Python-only perspective eggs might have a bunch of ease-of-use advantages, but from my point of view I'd suggest it's better that the developer (or Debian packager) takes the trouble to make it work with dpkg so all Debian users get to maintain the consistency they're used to. My 2c, etc, d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
