Djangorecipe always forces the download of latest packages about djangorecipe HOT 8 CLOSED

I'll probably look at it early next week. (Note: feel free to ping me if I haven't done anything by wednesday :-) )

For downloading, we use buildout's standard zc.recipe.egg functionality. There was an earlier pull request (see https://github.com/rvanlaar/djangorecipe/pull/79/files), though, that fixed relative paths. That's an option from buildout that djangorecipe had to explicitly pass to zc.recipe.egg.

In the same way, we might need to explicitly pass along the 'newest=False' option. At least, that's the direction I'd be looking at.

btw, could you look which version of buildout and setuptools you're using? If 'newest=false' it could be anything :-) And they changed quite a lot in setuptools in the last months... Though I suspect it is djangorecipe I'll have to look at and not setuptools.

from djangorecipe.

I confirmed this problem on my Debian box now.

If I list my installed eggs, I find:

zc.recipe.egg-2.0.1-py2.7.egg/
zc.buildout-2.3.1-py2.7.egg/

The annoying bit is that one of my eggs in ${buildout:eggs} uses numpy - as a result, it downloads and re-compiles it, what takes some time at new deployments.

from djangorecipe.

If the Debian numpy is good enough, Google for "syseggrecipe" :-)

On vrijdag, 6 maart at 7:36 p.m. André Anjos wrote:

I confirmed this problem on my Debian box now.

If I list my installed eggs, I find:

zc.recipe.egg-2.0.1-py2.7.egg/
zc.buildout-2.3.1-py2.7.egg/

The annoying bit is that one of my eggs in ${buildout:eggs} uses numpy - as a result, it downloads and re-compiles it, what takes some time at new deployments.

---

Reply to this email directly or view it on GitHub:
#88 (comment)

from djangorecipe.

I know of this one, but, why shouldn't "newest = false" work in this case?

from djangorecipe.

Actually, since zc.buildout gave up the "isolated python" ideas from the 1.x branch, syseggrecipe should not be a required recipe anymore. If newest = false is set, then zc.buildout should just re-use packages existing on the "system" (i.e. the Python environment used to bootstrap), if possible (i.e., there are no other version requirements that conflict or require you to upgrade).

Or am I totally wrong here?

from djangorecipe.

You are at least partially wrong here :-)

You're right that buildout doesn't try to provide an isolated python. But The only packages buildout knows about are the packages it manages itself (in the local eggs/ cache folder or a global egg cache if you configured it). Buildout doesn't know about packages you installed system-wide.

So if you depend on numpy, buildout will install numpy for you.

The trick of syseggrecipe is that it does look for globally-installed packages. If found, it installs them as a development egg in development-eggs/. Where buildout finds it, so that it doesn't need to download it again.

Question: the django that you expect buildout to re-use, is that a django you installed globally? "pip install django"? Or is it a django from buildout's own egg cache?

from djangorecipe.

I understand, though this is unexpected: the python environment is not isolated but implicitly ignores installed eggs.

The egg I'm referring to is globally installed, clearly - therefore my confusion.

I think you can safely close this problem in this case.

from djangorecipe.

It is quite hard to reliably figure out everything that's installed globally. So many locations, so many different package name/directory name complications...

So buildout only explicitly manages what it can manage and what it explicitly knows about (=what it installed).

Anyway, good that it's clear now :-)

from djangorecipe.