5

Short version: Is it possible to use the -e parameter in requirements.txt with a path where the editable package should be installed?

First approach

requirements.txt:

-e git+https://github.com/snake-soft/imap-storage.git#egg=imap-storage

Pro: Automated install

Contra: Editable directory is inside virtualenv src folder (not in workspace)

Second approach (Edit: Don't use this until you know what you're doing, look at bottom)

If i clone the repo and installed it like this (virtualenv activated):

cd /home/user/workspace
git clone https://github.com/snake-soft/imap-storage.git
pip install -e .

Gives the structure i want:

workspace
├── imap-storage
├── django-project  # uses imap-storage module

I have what i want. The repository (imap-storage) lays parallel to the django-project, that uses it. It is importable because it is installed inside the virtualenv.

Pro: Editable directory is inside my workspace

Contra: Not automated, not intuitive

Goal

  • pip install -r requirements.txt to install module from git (like first approach)
  • Module is in pythonpath of virtualenv -> importable
  • Editable working dir of the module is in my workspace (like second approach)

PS: Or am i completely wrong-thinking and should go for something completely different?

Frank
  • 1,959
  • 12
  • 27
  • 2
    Probably wrong-thinking but it's not entirely clear what exactly you want to accomplish. Why should `requirements.txt` be allowed to override the user's virtual environment? – tripleee Sep 24 '19 at 17:44
  • I dont want to override the venv. I want to pip install a python module from github in editable mode inside my workspace using requirements.txt. Technically it works. I done it manually like i wrote in second approach. I only want to implement that behavior inside requirements.txt for developing both projects in parallel. (Django-project uses this module) – Frank Sep 24 '19 at 18:57
  • 1
    Well, the short answer is no, there is no way for `requirements.txt` to affect where `pip` installs something, let alone performs Git checkouts. It would be a rather nasty surprise if it did that anywhere else than in the current directory. – tripleee Sep 25 '19 at 04:33

1 Answers1

1

Why did i ask such a crazy question?

I thought i could make my life a little bit easier when both (package and Django project that is using this package) are laying editable inside my workspace because i work on them in parallel.

My résumé

I tried it a little bit with the second approach and at the end, i decided to prefer the first approach.

Reason

With both methods pydev won't show it as an installed package.

When mix both methots like that:

  1. install package via requirements.txt (with the -e switch)
  2. uninstall it
  3. clone it into (eg. ~/workspace/)
  4. install it with the 'pip install -e .' inside the package

Then you will end up in a bad situation. The 'virtualenv/src/' directory won't be deleted and is recognized as source for the package inside pydev. When running the Django instance that uses that package, it runs the package-code from '~/workspace/'.

Suggestion

Use the first approach, import that source dir as project in pydev ('virtualenv/src/') and make a link inside the file-manager of your choice. It will save you from a complicated mistake.

Frank
  • 1,959
  • 12
  • 27