-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: use virtual env for installation #167
base: main
Are you sure you want to change the base?
Conversation
|
||
$ sudo -H pip install -e . | ||
$ python3 -m venv ~/luma-env |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to use:
python3 -m venv .venv
.venv/bin/activate
I think IDEs like vscode and tools like pyenv will sniff out a .venv
directory and will auto-activate it.
Is there any reason not to stick to that convention?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or are you aiming to pull all the dependencies for all sub-projects into one place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason not to stick to that convention?
I didn't know that IDEs like vscode and tools like pyenv will sniff out a .venv directory and will auto-activate it
, but maybe I'm just old-skool :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason not to stick to that convention?
I like to know where my virtual envs live, explicitly, in this case ~/luma-env
, and since I didn't know about that convention (and new users wont either i'd guess) I chose this.
fixes #166