Setuptools in SVN now provides preliminary support for installing eggs in
.egg-info directory style, so that setuptools-based projects can be wrapped
by system packagers who wish to avoid using .egg files or directories. In
addition, you can now use setuptools to install non-setuptools packages
I've just added experimental preliminary support for the .egg-info file
convention in Subversion. It makes the assumption that an .egg-info file
will contain the standard distutils "PKG-INFO" data, that the distutils
generate for source distributions and that existing egg formats include as
an
At 09:08 PM 11/27/2005 +0100, Josselin Mouette wrote:
Removing the dependency checks entirely and replacing them with Debian
dependencies is definitely an option, and I happen to prefer it slightly
to the necessity of adding empty .egg-info files to all python module
packages.
Just a reminder:
At 05:04 PM 11/25/2005 +0100, Janusz A. Urbanowicz wrote:
Opt out is evil in any circumstances, it should be always opt in, and not
too easy to do so.
Um, running setup.py or easy_install *is* opting in. I was just pointing
out that there are ways to restrict what you're opting in *to*, and t
At 10:28 AM 11/25/2005 -0500, Phillip J. Eby wrote:
Actually, I'm increasingly tempted to PEP the idea of a
name-version.pkg-info file being installed alongside the code as a standard
Python distutils feature. This discussion has made it clearer (even to
me!) how useful such a thing wou
At 04:22 PM 11/25/2005 +0100, Janusz A. Urbanowicz wrote:
On Fri, Nov 25, 2005 at 09:23:04AM -0500, Phillip J. Eby wrote:
> Now, it's possible for an individual coder to write an application or
> library that invokes easy_install itself, but anybody can write bad code
> and that&#
At 03:30 PM 11/25/2005 +0100, Vincenzo Di Massa wrote:
Alle 15:05, venerdì 25 novembre 2005, Phillip J. Eby ha scritto:
> It seems to me like the simpler solution is just to have the packages
> install the .egg-info, and nobody has to maintain a mapping database
> because the setup
At 01:39 PM 11/25/2005 +, Paul Moore wrote:
On 11/25/05, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> Sorry... that's what I meant; don't deb an egg... install it as an egg,
> outside of the Debian package management system. As an egg, it is under
> development and not ready for release as a d
At 01:52 PM 11/25/2005 +0100, Josselin Mouette wrote:
It could do it by simply trying to import the module.
Python's import mechanism is fragile in the presence of failed imports that
aren't explicitly trapped, and in Python 2.3 it's even more fragile because
only the *first* attempt to impor
At 01:07 PM 11/25/2005 +0100, Janusz A. Urbanowicz wrote:
On Fri, Nov 25, 2005 at 10:29:56AM +, Donovan Baarda wrote:
> On Fri, 2005-11-25 at 01:33 -0500, Phillip J. Eby wrote:
> [... long informative explanation of egg...]
> In particular, will an egg wrapped inside a Debia
At 11:34 AM 11/25/2005 +, Paul Moore wrote:
On 11/25/05, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> On thing about this worried me;
>
> If TurboGears depends on an "egg'ed" ElementTree, what happens if a
> system has ElementTree installed as a non-egg package? Does installing
> TurboGears as
At 11:54 AM 11/25/2005 +0100, Vincenzo Di Massa wrote:
Alle 11:04, venerdì 25 novembre 2005, David Arnold ha scritto:
> But, if compatible versions of those dependencies are already installed
> as Debian packages *without* egg metadata, will these be ignored?
Yes, they will.
> Even if it was po
At 10:29 AM 11/25/2005 +, Donovan Baarda wrote:
On Fri, 2005-11-25 at 01:33 -0500, Phillip J. Eby wrote:
[... long informative explanation of egg...]
So it sounds like egg duplicates much of the functionality of the Debian
Package manager, but also extends it slightly in python-specific
At 09:04 PM 11/25/2005 +1100, David Arnold wrote:
-->"Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
Phillip> I would like to clarify the phrase "shipped as an egg",
Phillip> though. To me, that would mean that the developer is
Phillip> di
At 12:54 PM 11/25/2005 +1100, David Arnold wrote:
So, if a system package, shipped by the upstream developer as an egg, is
"unpacked" into a directory structure, and its metadata is maintained
in a .egg-info file somewhere in sys.path, non-system eggs will have all
they need to operate correctly?
At 09:30 AM 11/25/2005 +1100, David Arnold wrote:
-->"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> runtim
At 12:39 PM 11/24/2005 -0800, Robert Kern wrote:
I'm not suggesting that /usr/share/.../ should be the only place to find
.egg-info directories. Simply that pkg_resources would scan
sys.path+['/usr/share/.../'] and treat the ones found in /usr/share/.../
as if they were in /usr/lib/pythonX.Y/sit
At 07:54 AM 11/25/2005 +1100, David Arnold wrote:
From a Python-centric viewpoint, Debian's (and RedHat, Gentoo, Solaris,
etc) packaging mechanism, however great, covers only one of the many
possible platforms that an application might need to support.
From a Debian-centric viewpoint, dependency
At 09:10 PM 11/24/2005 +0100, Josselin Mouette wrote:
A sane way, first of all, means a consistent way. Having two sorts of
Debian python packages is a no-go. Therefore, if we want to switch to a
new way of distributing packages, there has to be some serious grounds
for it. Currently, the picture
At 11:36 AM 11/24/2005 -0800, Robert Kern wrote:
Phillip J. Eby wrote:
> Note, by the way, that those two things are the only essentials here, as
> best I can tell, and I've already stated my willingness to change *how*
> those two things get accomplished. For clarity, I will re
At 07:27 PM 11/24/2005 +0100, Josselin Mouette wrote:
Looks like I mistakenly hoped it was possible to change things on
technical grounds, but if you're rebutting any technical discussion as
"irrelevant", there's probably not much to do.
On the contrary, quite useful technical discussion about
At 06:13 PM 11/24/2005 +0100, Josselin Mouette wrote:
Le jeudi 24 novembre 2005 à 11:43 -0500, Phillip J. Eby a écrit :
> That's an interesting perspective, but it's viewing the world through
> vendor-colored glasses. Unless the project developer is wearing similar
> glasses
At 06:03 PM 11/24/2005 +0100, Josselin Mouette wrote:
Le jeudi 24 novembre 2005 à 11:46 -0500, Phillip J. Eby a écrit :
> And finally, and most importantly, you're ignoring the fact that this
> discussion began because a Debian developer wanted to package a successful
> egg-using p
At 04:20 PM 11/24/2005 +0100, Josselin Mouette wrote:
Le jeudi 24 novembre 2005 à 10:14 -0500, Phillip J. Eby a écrit :
> At 01:44 PM 11/24/2005 +0100, Josselin Mouette wrote:
> >They only introduce more complexity, instead of bringing real features.
>
> Please read the hundreds
At 03:49 PM 11/24/2005 +0100, Matthias Urlichs wrote:
Hi,
Christopher Lenz:
> (And no, I'm not going to repeat the numerous attempts by Phillip to
> politely and comprehensively explain it all.)
>
Sorry -- I don't buy that. I've read all these messages too, and I also
don't know what's in the me
At 01:44 PM 11/24/2005 +0100, Josselin Mouette wrote:
They only introduce more complexity, instead of bringing real features.
Please read the hundreds of kilobytes of messages I've already posted on
this thread, and then when you're done, read these much shorter bits of
documentation for some
At 12:25 AM 11/24/2005 +0100, Matthias Urlichs wrote:
Phillip J. Eby:
> I'm also debating whether this option should also require the --record
> option, since there might otherwise be no way for an external packaging
> tool to know which files and directories belong to the ins
At 10:39 AM 11/24/2005 +1100, David Arnold wrote:
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
Cer
At 11:17 PM 11/23/2005 +, 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
hav
At 10:07 PM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I try to use very long names for options that can have damaging effects
if used indiscriminately. A project that's installed the "old-fashioned
way" (which is what this does, apart from adding .egg-i
At 10:00 PM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I was referring to how the distribution is *installed*. You don't use
things directly from a deb file, they have to be installed on the
system. When you install an egg, you must use one of the three forms, or
At 08:12 PM 11/23/2005 +0100, Matthias Urlichs wrote:
Hi,
Phillip J. Eby:
> I'm thinking that perhaps I should add an option like
> '--single-version-externally-managed' to the install command so that you
> can indicate that you are installing for the sake of an externa
At 04:53 PM 11/23/2005 +, 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 p
At 12:17 AM 11/23/2005 -0600, Bob Tanner wrote:
Bob Tanner wrote:
>> I don't think Debian should use the egg structure. It apparently relies
>> on building a long sys.path (even though through only a single .pth
>> file);
>
> I'm not sure of how .eggs are implemented, but I'm going to cross-post
d within that
distribution.
I'll try to use "project" in your sense and "package" in the
Python sense whenever I can.
Great - and let's use "Debian package" to mean the thing that manages the
installation of a project containing packages. :)
At 11:53 AM 11/23/2005 +1100, David Arnold wrote:
-->"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> develope
At 01:40 AM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I find that surprising, since I only use CGI if I'm not concerned about
the start time. It's not like there aren't dozens of "long-running
process" solutions for Python web apps including m
At 01:21 AM 11/23/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their
dependencies as eggs, you are stating a contradiction in terms. Eggs
are not merely a distribution
At 11:51 PM 11/22/2005 +, John J Lee wrote:
1. Does the above affect your concern about reading many zip files?
2. I understand your concern about memory usage (though the above seems to
make it a non-issue in practice, if used sensibly), but I must have missed
the argument you made for setu
At 11:56 PM 11/22/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Debian should provide the packages, but not as eggs.
For packages that only operate as eggs, and/or require their dependencies
as eggs, you are stating a contradiction in terms. Eggs are not merely a
distribution
At 02:00 PM 11/22/2005 -0600, Ian Bicking wrote:
An egg and Python packages don't map 1-to-1. An egg can contain multiple
packages (which is fairly uncommon so far), but also a top-level package
can exist in more than one egg (i.e., namespace packages, like
zope.interfaces or paste.script). T
At 09:54 PM 11/22/2005 +0100, M.-A. Lemburg wrote:
In order to keep compatibilty with the existing wide-spread
approach to install packages in site-packages/ using "python setup.py
install", it should be possible (and I believe this should be the
default to not disrupt existing usage and document
At 02:32 PM 11/22/2005 -0600, Bob Tanner wrote:
The ultimate goal is to debianize TurboGears, reading the above, and other
posts using the legacy site-packages (non-egg) installation will "break"
TurboGears?
If by that you mean, will you be able to create a Debian-packaged
TurboGears without e
43 matches
Mail list logo
