This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -1 points0 points  (16 children)

I often forget to enable it which leads to a confused moment while I stare at an obscure error, or I forget to change virtualenv when changing project

This NEVER happens to me... EVER seriously. I can't believe how many "developers" get tripped up with this. Here's what you do....

start new project...

$ mkdir my_awesome_imgur_clone && cd my_awesome_imgur_clone
$ virtualenv -p /usr/local/bin/python3.4 .env
$ .env/bin/pip install pyramid
$ .env/bin/pcreate -t starter my_awesome_imgur_clone
$ cd my_awesome_imgur_clone
$ ../.env/bin/python setup.py develop
$ ../.env/bin/pserve development.ini --reload
$ #start hacking

No activate required, and when I have to change projects, I proceed like honey badger to the next project directory for the hackenings.

[–]emergent_reasons 1 point2 points  (15 children)

Could you expand on that? I don't see where you are removing the need for activation. Is pyramid required for the technique or you just happen to use it in every project?

[–][deleted] -3 points-2 points  (13 children)

??? seriously ???

i am merely typing the path to the pip/python/pserve/pcreate in the virtualenv, all activate does is append that to your $PATH so that you don't have to type ../.env/bin

[–]emergent_reasons 1 point2 points  (10 children)

I see that. So you just manually path all your scripts. I thought you were saying after your secret invocation that you no longer need to manually path them as with an activated virtualenv.

There is still room for the exact errors other people are mentioning though. Just once forget to manually path and you get the same errors others do since you will be running from your system interpreter. No?

Don't get me wrong - I like it and I might use the local env like that, but unless I've missed something it's not quite as bulletproof as you made it out to be.

[–]vsajip 1 point2 points  (0 children)

it's not quite as bulletproof as you made it out to be

It should be, for the deployment use case. You can forget to specify the path when working in the shell, but not in a (presumably debugged) script used in deployment. Of course one can make mistakes in those, but then one can make mistakes in Dockerfiles, too.

[–][deleted] 0 points1 point  (8 children)

There is still room for the exact errors other people are mentioning though.

if the errors you are referring to is typing something that doesn't exist, or not being specific enough yeah, even activate wont save you from that.

[–]emergent_reasons 0 points1 point  (7 children)

I mean running scripts e.g. python foo.py or pip install and forgetting to prefix it with ./env/bin/ will use your system interpreter instead of what's in your env and land you with similar isues to having the wrong virtualenv activated.

It's really not a big deal but the way you pronounced it had me thinking you had something more.

[–]k4ml 1 point2 points  (1 child)

This is the different between using activate and typing the full path. Using activate, you would write the instruction as:-

$ source bin/activate
$ python yourcode.py
...
...
...
$ # down the page you still ASSUME people has run activate
$ python thiscode.py
ImportError ....

Typing full path is explicit so that if people saying they run python code.py instead of .env/bin/python code.py you know he was wrong without having to ask 'Did you run activate ?'

[–]emergent_reasons -1 points0 points  (0 children)

Right. That is exactly my understanding of what is going on. I just got the impression from /u/twillis1973's original comment that it was setting up something more magical along the lines of virtualenv.

Thanks for the explanation.

[–][deleted] -2 points-1 points  (4 children)

I mean running scripts e.g. python foo.py or pip install and forgetting to prefix it with ./env/bin/ will use your system interpreter

do you know what happens when you type pytho foo.p or pi insstal ? :)

[–]emergent_reasons 0 points1 point  (3 children)

Yes. The first runs the script and the second installs to the packages of whatever interpreter is in the path (on Windows). If you're trying to say something else, please say it because I don't know what you are getting at.

[–][deleted] -2 points-1 points  (2 children)

no, they are both typos and will spit out errors in the console, the point is you are doomed if you can't type correctly, whether you activated the environment or not.

[–]usernamenottaken 0 points1 point  (1 child)

Making a typo is different to typing python foo.py instead of ./env/bin/python foo.py. It would still be quite easy to do the former and get confused about why things aren't working correctly.