On 8/2/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> It has bothered me for a while that Django's installation (setup.py)
> requires a working Internet connection. That's because we're using
> ez_setup/setuptools
> (http://peak.telecommunity.com/DevCenter/setuptools), which downloads
> the setup program automatically if you don't have it installed.
>
You can specify a local url in the use_setuptools, e.g.
import ez_setup
import os
ez_setup.use_setuptools(download_base = os.path.join("file://",
os.getcwd()) + "/")
(not the most robust, but you get the idea)
This will look for the egg in the same directory as the setup.py is
run from, usually the django source. This way you can bundle the egg.
The nice thing here is that it shouldn't intefere with anyone using
setuptools already.
> The thing is, we don't actually *use* any of the advanced
> functionality in setuptools. Frankly, the only reason we're using it
> is because setuptools makes it easier to specify which files we want
> to include in the distribution (via some globbing syntax that's more
> advanced than the standard Python distutils). This is because we
> figured it'd be too much of a pain to create a MANIFEST file and keep
> it updated. Yes, this is a *horrible* reason to use setuptools rather
> than distutils.
>
If you have a lot of shared data to include this is actually a very
good reason to use setuptools :)
Projects like matplotlib got mired in so many installation issues
trying to get all their shared data installed correctly on so many
configurations that they switched to setuptools (well, that was one of
the main reasons I think).
> So, convince us to continue using setuptools. What incentive do we
> have to keep using it? I'm not sure the convenience of easily being
> able to specify a manifest outweighs the horrid stain of requiring an
> Internet connection just to install our software. Are there any other
> ways we can take advantage of it, perhaps?
>
Well, if no feature other than the manifest management is used then
there isn't much incentive to keep using it. However, folks like JP
mentioned some of the more advanced features which could be used in
future.
The main one which springs to mind is optional dependencies. If
database eggs are available then you could go "easy_install
Django[sqlite]" to pull in the sqlite egg for example. This
potentially can make installation a lot easier, provided eggs for each
of the supported databases are available of course :)
Entry points are potentially useful if you want to provide optional
components or pluggable parts. I think they are more useful to an app
using django rather than django itself.
Another useful part of setuptools is the pkg_resources part which lets
you locate and open shared data from inside the egg (which could be a
zip file). This is a more robust replacement for __file__.
> I really want to be convinced to continue using setuptools, but I'm
> drawing a blank... Insights are appreciated!
>
I think this is a tricky question to answer. Projects like turbogears
have been built from the ground up using eggs, so the dependency logic
in setuptools is vital to them. Django has been built to have as few
deps as possible, so this aspect is not particularly useful.
I think keeping setuptools keeps more options open in future. However
if the default distutils is used instead then I would ask that django
be kept egg compatible, i.e. don't do anything fruity in the setup.py
which breaks easy_install. It's quite annoying to write your own
setup.py so you can depend on other packages :)
cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
