Show HN: Virtualenv-mv – Move (rename) Python virtualenvs

Re:Show HN: Virtualenv-mv – Move (rename) Python virtualenvs by m_mueller on Sunday June 12, 2016 @05:21AM (#11887341)

Well, sometimes you need an architect rather than a committee. This is one such time.

Looking at the whole thing superficially (i.e. just throwing something at the wall here), this is how I'd have done it:

* packages are by default always installed in user space.

* package manager is built into import system. Importing a package that's not in the user's environment yet will lead to something like pip install at script startup.

* import statements understand versions. By default the latest version of a package is loaded. If something else is needed, the programmer can specify the specific one.

* for most third party packages that are publicised in pypy it's recommended to bind all imports to specific versions of dependencies, so it can be tested in this configuration at release.

[ Parent | on HN ]

Re:Show HN: Virtualenv-mv – Move (rename) Python virtualenvs by devnonymous on Sunday June 12, 2016 @07:47AM (#11887671)

  > package manager is built into import system.
  > Importing a package that's not in the user's
  > environment yet will lead to something like
  > pip install at script startup

Here's a nifty little recipe I came up with to do just this by exploiting the import hooks introduced in py3.4

  http://lonetwin.github.io/blog/html/2016/05/16/auto_install_missing_python_modules.html

[ Parent | on HN ]

Re:Show HN: Virtualenv-mv – Move (rename) Python virtualenvs by maweki on Sunday June 12, 2016 @09:30AM (#11888007)

Please don't do that. Provide a requirements-file with the appropriate dependencies and their versions to use with `pip install -r `

[ Parent | on HN ]