On 11/25/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:34 AM 11/25/2005 +0000, Paul Moore wrote:
> >- what would happen if I downloaded the TurboGears egg and just put it
> >on sys.path - no easy_install or whatever?)
>
> You could import stuff from it, but it might or might not work. Where it
> explicitly require()'s things or tries to load a plugin, you'll get
> DependencyNotFound errors.
OK, I made an assumption which I wasn't clear about here. Assume I've
done what I currently do, and installed all of its dependencies.
Will it work now? If not, why not?
*As a user* I want to opt out of the easy-install experience (you
state elsewhere "EasyInstall is the (rather primitive) package
manager..." - and I'm happy sticking with the equally primitive
Windows package management approach).
Actually, I think I know the answer (although I've thought that before
as well :-)) - it will work, as long as I didn't screw up with my
manual dependency management. A screw-up equates to me getting a
DependencyNotFound error. If that's correct, then I'm more or less
fine with it.
But...
To install a non-egg Python package is just a matter of:
1. Running a bdist_wininst exe (or apt-get on Debian, etc), or
2. Dumping the package directory in site-packages (Debian folks,
please don't scream :-))
For an egg, like TurboGears, my options (assuming I don't want to use
easy_install) are:
1. Wait for someone to wrap the TG egg in a system package, or
2. Put the egg somewhere (likely site-packages), then create or
modify a .pth file by hand to add the egg to sys.path.
In both cases, (1) is the managed option, and (2) is the unmanaged
one. And (2) is *harder* for eggs. (1) is just as easy for me either
way, but I assume that's just because the extra difficulty is passed
onto the developer of the system packaging process.
I find this jarring, because eggs are presented as a "zero installation" format.
And I'd be curious to know what sort of reaction I'd get from the TG
community if I posted a message saying I'd dumped various eggs into
site-packages, manually fiddled with .pth files, and TG wasn't
working. :-)
> The drop-in-and-go aspect of eggs is mainly used for application plugins in
> systems like Trac, although in truth they actually use the discovery
> machinery to scan their plugins directory and identify which plugins are
> loadable - that is, which plugins can have all their dependencies met.
Yes. Plugins are a clear benefit. I don't think *anyone* is arguing
that this is an issue.
> This is one reason that runtime integrity checks are important; an app can
> detect that it doesn't have what's needed for a given plugin, and skip
> loading it. This is also why dependency resolution needs to be able to
> roll back if it fails, even for deeply-nested dependencies.
OK. And I see that a plugin can need a system library (a Trac
"progress chart" plugin needing PIL installed, for example). And
non-egg installs can't provide that discovery mechanism directly. OK.
You've got that covered (as best you can) with the single egg-info
file option.
(From another posting)
>>So, as a package developer, if I want to use egg metadata or plugin
>>support, I have to buy into the whole egg experience, including the
>>installation stuff.
>Actually, I thought you wanted eggs to be wrapped in system packages, so
>that you don't have to use the "installation stuff". That is, after all,
>what this extended thread is about: providing system packages of egg
>projects, and allowing egg dependencies to be met by system packages.
Different contexts. If I'm *developing* a package (not something I do
often) I can see the benefits of metadata, package resources, etc. I
don't care one way or the other about the installation side - but it
comes as part of the whole bundle, for better or worse.
As a *user* of other people's packages, I want to use system managed
packages. As a *Windows* user, I'm a pain, because I expect the
developer to supply that system managed installer, rather than the
suppliers of my distribution.
(and round full circle) As a *developer* again, I don't have a way of
satisfying my Windows user's requirement for a wrapped version of my
egg.
It's somewhat like the old days, when python setup.py install existed,
but bdist_wininst didn't. Windows users had to take pot luck as to
whether a particular package would be available to them (because they
couldn't use the "standard" setup.py install when C extensions were
involved).
But while I'm only developing packages for my own use, it's pointless
building fancy infrastructure. And clearly people like the TurboGears
developers, who are aiming at a significant user base, don't have many
users asking for Windows installers at the moment, so things will stay
as they are for the moment.
[An only vaguely related question - is the feature of generating
wrappers for scripts based on entry points an easy_install feature, or
an egg feature? If so, what happens to it with a system package
wrapping the egg? I ask because I see that Kid has swiched from
bdist_wininst to egg as its distribution format, as far as I can tell,
just for the script-wrapper feature - so can I use the manual option
(2) above to install Kid???]
Must stop reading and replying to posts, and do the research...
Paul.
