Allow to installation of more packages into a venv

[kwbr]

Say I have installed beet (http://beets.radbox.org/) with pipsi. beet has some optional dependencies which need to be installed if you enable one of the provided plugins. To use discogs you need the discogs-client package, to use lastgenre you need the pylast package.

So, in order to use those plugins it should be possible to install more packages into the venv.

[Qu4tro]

You can.

Go to ~/.local/vens/beets/ Activate virtualenv: source bin/activate pip install pylast discogs-client deactivate

Maybe we should add this to the README?

[kwbr]

Mentioning this in the README would be great.

But as I see it, because pipsi is a wrapper around virtualenv and may use another virtual environment provider in the future, the installation of another package into the venv should also be wrapped.

[Qu4tro]

I understand your issue, but I'm not sure about that solution. I'm sure there are a lot of other similar issues(alongside installing additional packages), that are only solved with virtualenv access.

My idea was using an optional dependency to vex, to allow something like:

pipsi --virtualenv=beets pip install pylast discogs-client

On the other hand, using vex or any other wrapper on its own, it's probably better to avoid feature-creeping.

Maybe a small chapter on README to explain this issue and advice to new users?

[RonnyPfannschmidt]

This one is depending on #52

[RonnyPfannschmidt]

Aside from package we also should handle scripts as per #29

[glyph]

Another great example here:

pipsi install devpi-web and pipsi install devpi both fail.

But, pipsi install devpi-server doesn't install devpi-web, which means I don't get the nice web UI.

[dhouck]

This also makes it really difficult to use Jupyter, especially if you want multiple kernels or to work with other packages in Jupyter.

[vlcinsky]

What about using sort of requirements.txt, but named according to virtualenv I want to use.

E.g. I want to install devpi with devpi-client and devpi-web.

I would create a devpi.requirements (just properly named requirements.txt):

devpi-client
devpi-server
devpi-web

and run:

$ pipsi install -r devpi.requirements

It would create virtualenv named devpi.requirements, install into it all the dependencies and symlink all the CLIs available. The file devpi.requirements would be placed into root of the virtualenv under name requirements.txt to have base for later upgrades.

It would be recommended to use the requirements without frozen version to allow updates.

With CLI symlinks and multiple packages installed into one virtualenv it is a bit more likely, more than one virtualenv will have CLI with conflicting name. This can happen today, but it would be a bit more likely.

[kwbr]

stale