having trouble with virtualenvwrapper - need to run 'source ~/.profile' every time.

[Jimmy Pants]

...every time I open a terminal, that is. As I understand it, .profile is the file to edit in Linux Mint, and it does exist, with some basic code in it, in my home dir. So, per this tutorial, I added the following to .profile:

export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
source /usr/local/bin/virtualenvwrapper.sh

But I still have to run $ source ~/.profile before I can run workon and the rest. I went
so far as to reboot, even...

[Thomas Lockhart]

On 10/16/13 8:29 AM, Jimmy Pants wrote:

...every time I open a terminal, that is. As I understand it, .profile is the file to edit in Linux Mint, and it does exist, with some basic code in it, in my home dir. So, per this tutorial, I added the following to .profile:

Your terminal is being opened without specifying it as a "login shell". Not sure which terminal program you are using so you will need to check on options; for xterm it is the -ls option.

hth

                          - Tom

[Jimmy Pants]

Does gnome-terminal make sense to you in this context? I popped up "edit" on the terminal launcher and that's in the Application field. I would, theoretically, add whatever option for gnome-terminal specifies it as a login shell?

Testing this, I added --login to the field, per this page, but it didn't ask for a login, nor did it run .profile.

Not sure if I'm barking up the proper tree here, natch.

[Bill Freeman]

The file you want (assuming that your shell is bash) is .bashrc because it is run every time a bash shell is started, even if it is not a login shell.

Note, however, that settings that shouldn't be done multiple times, such as appending ":$HOME/bin" to the PATH, should be protected with an if so they only happen once, no matter how many sub-shells you start (such as by running something in parentheses), so that PATH doesn't grow without bound.  The WORKON_HOME and PROJECT_HOME settings don't suffer from this problem because it doesn't hurt to set them again to the same value.  I don't know about sourceing virtualenvwrapper.sh.  (Guard variables are your friend.)

For some of this stuff it may also be possible to set the environment of the X session, making it available in the environment of shells that are started by the window manager, but you'll have to do your own research on that.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e3e173c4-56a5-4d16-a449-6da333fbb74e%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[J. Paskaruk]

That's the one, thank you so much! I saw in the comments of .profile that it would not be read if there was a .bashrc file present, so my next step was creating that file and putting those lines in it, but I'm very afraid of pooching my install. Noob, like I said. :>

I have Aspergers, so I'm not clear on what you meant by "I don't know about sourceing virtualenvwrapper.sh.  (Guard variables are your friend.)" - I'm assuming, though, that you're referring to a security concern in this line, presumably based on the idea that someone could access virtualenvwrapper.sh and put malicious code in there.

If I've assessed your comment correctly, is there a good, basic tutorial on {guard variables}, as well as the larger schema into which they fit? Preferably one that *does* assume intelligence, but does *not* assume a lot of existing knowledge on the part of the user?

Whatever the case, thank you again for the new knowledge about .profile and .bashrc. :>

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/kDehG6wHqiA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0uVGKfx_b%2BBX4-h8EA3YPqDipJStL5TRE8fN_gW6dJvCQ%40mail.gmail.com.

[Bill Freeman]

What I mean by "I don't know about sourceing virtualenvwrapper.sh" is that I don't know, and don't have the inclination to research, whether, having sourced the file in a shell, you should avoid sourcing it again in a sub-shell.

What I mean by guard variables is that you could, at the end of your .bashrc, export a variable that is unlikely to clash with the variables of other systems, e.g.;

    export BASHRC_HAS_ALREADY_BEEN RUN

And earlier in the file test the variable to guard against redoing the things that should not be redone.

    if [ "$BASHRC_HAS_ALREADY_BEEN RUN" -ne "1" ]; then

       # Put stuff that shouldn't be done twice here

    fi

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANabDd%2B2P08Ur%2BStcrg4Ynadg1fhWiFfK2%3D_nYJnhs4DSA3RTw%40mail.gmail.com.

[J. Paskaruk]

Ahh k. I took it out of .profile entirely and put it in .bashrc, so it should only be run the once. I'm the only significant user of this computer. Cheers!

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0sY8N%3DQ7%3D%2B_-X9AUBdyeDR9HcRsoK6w8vQKVwHptMwkVw%40mail.gmail.com.

[Bill Freeman]

Not strictly true.  .bashrc will get run again in a sub-shell.  For example, in your shell, you run a command, and that command is a shell script.  A new shell is started to run that script.  It inherits your environment variables.  But it also runs .bashrc.  That's usually not a problem, but there are corner cases where it is, so it's worth taking a little care in writing a .bashrc file.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANabDdKdW8909Gx_uT8%2BxucwkJCLPUDq1Sjn3apD3-J0vam1Sg%40mail.gmail.com.

[J. Paskaruk]

I will keep that in mind for sure - I'm always aware that there are little subtleties like that all around me, waiting to trip me up, so when someone explains one to me, I cleave to the info. I'm pretty paranoid about this kind of thing to begin with, which is why I removed it from the one when I added it to the other - if it only needs to be there once, then having it there twice is just stupidity, unless there is a demonstrable reason to do so.

I'm kinda suspicious of virtualenv in the first place because of this, but the sales pitch by that nice young man, Simeon Whatsisname, convinced me that it was a good idea to get a handle on it.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0sgi%2BtHNjnt3MjWq-vbwjmb2N8-a%2B1W-04rkdEgaXq2Aw%40mail.gmail.com.

[Bill Freeman]

virtualenv is, indeed, great stuff, and is unlikely to be your problem.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANabDd%2B66dnctrMzjOMs-RgL-LpQDWWbQHR5sEqQxZd3RKdxag%40mail.gmail.com.

[Dow Street]

And just a reminder that you can certainly use virtualenv without virtualenvwrapper. Every env you create with virtualenv will have a script to activate that env located at envname/bin/activate. For example:

Open your shell, cd to the desired directory, and create a new env:

$ virtualenv testenv
New python executable in testenv/bin/python
Installing setuptools.............done.
Installing pip...............done.

Activate the env:

$ . testenv/bin/activate
(testenv)$

Note that the prompt changed and is now pre-pended by the env name.

Deactivate the env:

(testenv)$ deactivate
$

The prompt changes back - env is deactivated.

R,
Dow

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0u--5FFifNqj9%3D%2B5tmALq2HS7WgkYRyA%3DTanS7swHnNJQ%40mail.gmail.com.

[J. Paskaruk]

Heh, just realized I made an out-of-context comment. This problem is actually solved, but I'm currently also having trouble connecting to MySQL, and am discussing that in another thread. Forgot which thread I'm in.

The potentially virtualenv-based problem is that python-mysqldb is installed, but the virtualenv Python can't see it, and I can't install it with pip. No idea, but I switched to sqlite. :>

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/020C04DA-081A-4B4C-9F1F-9DAC0603C59A%40prodigy.net.

[Bill Freeman]

If you installed python-mysqldb in the base python, perhaps by using synaptic, then you aren't supposed to see it in the virtualenv.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANabDdJttR%3Dq2NJHE7FcC94vCxjgBtayCOJq9%3DDfKoDPh5cZFg%40mail.gmail.com.

[J. Paskaruk]

Yah, was having trouble installing it within the virtualenv as well, though - ultimately, exiting the virtualenv and installing python-dev allowed me to install the mysqldb module (library? I'm still unclear on terms, sorry). anyways, problem is solved. :>

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0vGZc1xsZxDS7absb7pJ_FRcyBSr%3DMpnc7tmt%3DPzYtnYQ%40mail.gmail.com.