virtualenv / buildout / setuptools / six conflicts

[Theuni]

Hi,

did anyone notice that we're getting into trouble with the size of packages in a basic virtualenv growing? I always pin all my projects and just noticed that pinning will interfere with packages installed in a virtualenv that you're running buildout from. Specifically I now have to use whatever version of six gets provided by the virtualenv (or have to manually down/upgrade that outside of buildout).

I can work around that for now, but maybe its some input worth considering for the next steps ... 

There's even a few more packages nowadays. This is virtualenv 1.11.4 installing a Python 3.4 environment:

$ bin/pip freeze

appdirs==1.4.2

packaging==16.8

pyparsing==2.2.0

six==1.10.0

zc.buildout==2.8.0

Christian

[Leonardo Rochael Almeida]

Hi Christian,

This was caused by the un-vendoring of setuptools dependencies.

A workaround is to pin setuptools==33.1.1, the last dependencies-vendored version.

I've documented this issue and some bad effects of it here:

https://github.com/buildout/buildout/issues/338

Cheers

--
You received this message because you are subscribed to the Google Groups "Buildout Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buildout-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jim Fulton]

On Mon, Mar 6, 2017 at 4:46 AM, 'Theuni' via Buildout Development <buildout-development@googlegroups.com> wrote:

Hi,

did anyone notice that we're getting into trouble with the size of packages in a basic virtualenv growing?

Oh yes.

 

I always pin all my projects and just noticed that pinning will interfere with packages installed in a virtualenv that you're running buildout from. Specifically I now have to use whatever version of six gets provided by the virtualenv (or have to manually down/upgrade that outside of buildout). 

I can work around that for now, but maybe its some input worth considering for the next steps ... 

 

<Brainstorming>

Yup.  I'm not sure this is a bad thing.  By pinning versions and finding the environment is inconsistent, you know you have a problem.

OTOH, I imagine we could add an option that says: "assume environment versions are pinned", so that buildout wouldn't complain that they're unpinned.

I also think there should be better interoperability between buildout and requirements.txt.  For example, if your environment is controlled by requirements.txt, then there ought to be a way to tell buildout to consider the pins there.

Jim

--

Jim Fulton
http://jimfulton.info

[Theuni]

Hi,

On Monday, 6 March 2017 16:08:19 UTC+1, Jim Fulton wrote:

<Brainstorming>

Yup.  I'm not sure this is a bad thing.  By pinning versions and finding the environment is inconsistent, you know you have a problem.

Well, except that it starts to erode the purpose of the virtualenv. If we get bestowed with an arbitrary number of dependencies (that we can't override) then I don't know what virtualenv is actually doing us good for. I always accepted the setuptools/pip installation as a necessary evil.

Wasn't the idea to get a clean slate where we can install our dependencies without conflicting with the system? Seems like this isn't true any longer and might thus require taking a step back. 

I do agree that it's a good thing that buildout conflicts.

OTOH, I imagine we could add an option that says: "assume environment versions are pinned", so that buildout wouldn't complain that they're unpinned.

I also think there should be better interoperability between buildout and requirements.txt.  For example, if your environment is controlled by requirements.txt, then there ought to be a way to tell buildout to consider the pins there.

That could be an interesting stepping stone for people new to it. It may have drawbacks about buildout's clarity if the story around the integration it isn't clear. 

Christian