#29 virtualenv without --system-site-packages is hard to maintain
Closed: Fixed None Opened 10 years ago by kparal.

Our readme instructions suggest to create a virtualenv with manual symlinks. I have just found the disadvantages:

  1. When a system library is updated, the symlink is broken and you need to fix it manually.
  2. When you need to run an external task that depends on libtaskotron, you most probably want to run it in the same virtualenv. But the external task (let's say task-upgradepath) depends on further packages (let's rpmUtils from yum). That means you need to create some more symlinks. This might be OK for the task you develop yourself, but it might be quite annoying if you just want to run a task of someone else.

Both these problems create quite some maintenance burden. I wonder, do we have some objection against using virtualenv --system-site-packages (and updating the readme)? I have tried it and everything seems to work very well.


I have no problem with doing this. We may need to change it later if system lib versions conflict but for now, I can't see a reason not to do it.

If we install a package from PyPI, it takes precedence over system packages, so I hope there should be no conflict issues. I'll fix the readme.

Closed by commit rLTRN63ad1014c853.

The problem is that the bitbucket website is configured to display master branch by default, and I pushed to develop, therefore people can't see the improved instructions on the website at the moment. We can a) set the default branch to develop on bitbucket b) merge develop into master c) leave it be. I didn't do any of that, because I'm not clear what our desired workflow is.

The problem is that the bitbucket website is configured to display master branch by default, and I pushed to develop, therefore people can't see the improved instructions on the website at the moment. We can a) set the default branch to develop on bitbucket b) merge develop into master c) leave it be. I didn't do any of that, because I'm not clear what our desired workflow is.

d) leave it be and put a sign saying that we use gitflow and that master is for stable/released code.

Also, you could create a hotfix for this ticket and merge it into both master and develop.

Er, I meant put the sign into the readme file.

Tim changed the default bitbucket branch which solved the problem - the updated documentation is displayed by default. We can leave master in hibernation now, until we have a first public release.

Login to comment on this ticket.

Metadata