Re: "pip install scons" result in a broken installation that is unusable
Mats Wichmann <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <[email protected]> |
On 10/11/2018 11:33 PM, Fux Samuel (ID SIS) wrote: > Not using virtualenv is a personal preference, like not using Anaconda to install Python itself or like preferring pip over distutils. I don't like the additional step of activating the virtualenv because I would like to keep things as simple as possible for our cluster users. > > If virtualenv is a hard requirement for using SCons, then this should be added to the Readme.md file on github. Currently the Readme.md file states with regards to dependencies: No, it's not a hard requirement. It's a bit risky to "pip install" packages into an environment that is elsewise managed. To be less abstract, if most of your python comes from Linux distribution packages, then your package manager (dpkg, rpm, etc.) thinks it has control over those directories, and making changes outside of the package manager (pip install) leaves you in a "bets are off" state - something might change out underneath you as packages are upgraded/added/removed. So for this scenario, the suggestion is to use a virtualenv for working with additional things which _you_ want to be in control of, OR to tell pip to do a "user install", which puts the installed materials somewhere in a user's home directory rather than system locations (this would not make sense for you as you're trying to manage a shared installation). And if you are managing the Python installation yourself, the chance of conflicts is less, or at least, you can be in charge of them. _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users