4 ms·

virtualenvwrapper isn't part of virtualenv or python. Are you saying that the existence of virtualenv tells you there's something wrong?

• hkjgkjy 10y ago
  I would agree to that yes, as are most (all) languages. It would be very nice if the Python version was something specified in the project manifest. Don't know what is the popular build tool in python, but something like specifying the node.js version in the package.json file would be great. I think the reason it never works like that is that the language is written before the package manager and VM/compiler. In Clojure it's the other way around - the JVM and the package managers were there before the language. The Clojure compiler is a library that you include in your project.clj file like any other lib. Hence you can specify language version per project. That's a feature I would like to have in other programming environments.
• m_mueller 10y ago
  No, my point is rather: Why do we need virtualenv at all (and worse, more wrappers around it)? Why should, say, pip packages have any problems with each other as long as they aren't imported directly in a python sourcefile. It seems like versioning of packages isn't solved correctly at the interpreter level, that's why we have the virtualenv crutch.
  • neuroid 10y ago
    Why should, say, pip packages have any problems with each other as long as they aren't imported directly in a python sourcefile. Are you suggesting that package versions should be explicitly provided as part of import statements? Or that import statements should be mangled depending on the versions specified in setup.py?
    • m_mueller 10y ago
      > Are you suggesting that package versions should be explicitly provided as part of import statements? Yep, see also my suggestion in the other subthread.