Confusion.. After Cp virtualenv???

[Tom Brander]

This is probably just another newbie ignorance issue, but I think I'm getting confused on a higher plane, it used to be that I would never have noticed lack of pyc files..

I have been happily using Virtual env and wrapper for a while, I recently copied my mezzanine env from mezz3 to mezz4 mezz4 was made active and I did a bunch of upgrade work in it.. all seemed good..

Then I had to go into mezz4 an patch something in Django, it did not seem to work.. I then noticed that in mezz4 theer were no pyc files.. How can that be? So I wonder that that may be why the attempted patch did not work? (the error message was identified as from the virtual env mezz4 version but there is no pyc for that file)

Of course I'm more than a bit worried as to what revision is in which env and what is being executed.

I noticed that in mezz4 there is a locals directory with symlinks back to mezz3, and mezz3 does have all the pyc files I would expect..

What is happening? What part of the docs do I need to read?

Is it possible to do a true copy and have it be really isolated from the original it was copied from? Should that be the default since once I have moved on I'm likely to want to remove the old env?

I'll add that if I had not gone into this debug issue I never would have noticed any of this as the new revisions seem to work...(except for that patch which could just be a red herring.)

[Doug Hellmann]

On Feb 24, 2013, at 1:52 PM, Tom Brander wrote:

This is probably just another newbie ignorance issue, but I think I'm getting confused on a higher plane, it used to be that I would never have noticed lack of pyc files..

I have been happily using Virtual env and wrapper for a while, I recently copied my mezzanine env from mezz3 to mezz4 mezz4 was made active and I did a bunch of upgrade work in it.. all seemed good..

Then I had to go into mezz4 an patch something in Django, it did not seem to work.. I then noticed that in mezz4 theer were no pyc files.. How can that be? So I wonder that that may be why the attempted patch did not work? (the error message was identified as from the virtual env mezz4 version but there is no pyc for that file)

How did you apply the patch?

Of course I'm more than a bit worried as to what revision is in which env and what is being executed.

"pip freeze" will tell you what's installed in a virtualenv.

I noticed that in mezz4 there is a locals directory with symlinks back to mezz3, and mezz3 does have all the pyc files I would expect..

I don't understand what you mean there. What exactly is in the locals directory?

What is happening? What part of the docs do I need to read?

Is it possible to do a true copy and have it be really isolated from the original it was copied from? Should that be the default since once I have moved on I'm likely to want to remove the old env?

Copying virtualenvs is not supported very well, at the underlying layer. The environments have all sorts of paths hard-coded into them, and it sounds like you've hit on a case that the copy command doesn't address.

I'll add that if I had not gone into this debug issue I never would have noticed any of this as the new revisions seem to work...(except for that patch which could just be a red herring.)

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

[Tom Brander]

Doug, I really appreciate the patient reply, I dashed this off after a particularly frustrating day..

As a point of interest, I did try once again to copy a virtualenv, and then apply some pip updates it was a horror show.. some stuff made it some did not..I did not have the time to fully reason out what had occurred..  I'm wondering if it has anything to do with not specifying no-site packages? it almost seems that pip decides not to install something (or upgrade) if it finds it outside the virtual env.. I am however grasping at straws..

However based on now two occasions.. I vow not to use cpvirtualenv... unless I have a bunch of time on my hands.. I was using Ubuntu 12.10 64 bit with the system install of Python 2.73 I was using it with Mezzanine which itself installs Django so it was not a trivial install, which I then tried to upgrade after the virtualenv copy.

A "clean" install to a new virtual env worked fine..

This is not much help but could warn some people of cpvirtualenv dangers!

[Doug Hellmann]

On Apr 26, 2013, at 4:51 PM, Tom Brander <tombr...@gmail.com> wrote:

Doug, I really appreciate the patient reply, I dashed this off after a particularly frustrating day..

As a point of interest, I did try once again to copy a virtualenv, and then apply some pip updates it was a horror show.. some stuff made it some did not..I did not have the time to fully reason out what had occurred..  I'm wondering if it has anything to do with not specifying no-site packages? it almost seems that pip decides not to install something (or upgrade) if it finds it outside the virtual env.. I am however grasping at straws..

Yes, pip does decide that if something is already installed and visible, it doesn't need to be reinstalled in the virtualenv. That's one reason for never installing anything globally, and just using the virtualenv.

However based on now two occasions.. I vow not to use cpvirtualenv... unless I have a bunch of time on my hands.. I was using Ubuntu 12.10 64 bit with the system install of Python 2.73 I was using it with Mezzanine which itself installs Django so it was not a trivial install, which I then tried to upgrade after the virtualenv copy.

I never copy virtualenvs myself. The feature was submitted by someone else, and I don't even really understand the use case (why wouldn't you just build a new clean virtualenv using the output of "pip freeze"?).

A "clean" install to a new virtual env worked fine..

This is not much help but could warn some people of cpvirtualenv dangers!

I'm very tempted to just remove the feature entirely, because it seems it only rarely works correctly. For the time being, I've just added a warning to the documentation.

On Sunday, February 24, 2013 12:52:14 PM UTC-6, Tom Brander wrote:

This is probably just another newbie ignorance issue, but I think I'm getting confused on a higher plane, it used to be that I would never have noticed lack of pyc files..

I have been happily using Virtual env and wrapper for a while, I recently copied my mezzanine env from mezz3 to mezz4 mezz4 was made active and I did a bunch of upgrade work in it.. all seemed good..

Then I had to go into mezz4 an patch something in Django, it did not seem to work.. I then noticed that in mezz4 theer were no pyc files.. How can that be? So I wonder that that may be why the attempted patch did not work? (the error message was identified as from the virtual env mezz4 version but there is no pyc for that file)

Of course I'm more than a bit worried as to what revision is in which env and what is being executed.

I noticed that in mezz4 there is a locals directory with symlinks back to mezz3, and mezz3 does have all the pyc files I would expect..

What is happening? What part of the docs do I need to read?

Is it possible to do a true copy and have it be really isolated from the original it was copied from? Should that be the default since once I have moved on I'm likely to want to remove the old env?

I'll add that if I had not gone into this debug issue I never would have noticed any of this as the new revisions seem to work...(except for that patch which could just be a red herring.)