Poetry: Allow non-editable installations

[maggyero]

@sdispater, in https://github.com/sdispater/poetry/issues/730 you said:

The install command installs the current project in editable mode by internally creating a temporary setup.py file and executing pip install -e .. It does it each time install is executed to ensure that any new elements like entrypoints are properly installed.

Could you allow non-editable installations by adding a --no-editable _command-line parameter_ for these three commands:

• poetry install --no-editable
• poetry add --no-editable
• poetry update --no-editable

The documentation states that it is already possible for local dependencies, but with a develop _file parameter_ in the pyproject.toml file:

If you don't want the dependency to be installed in editable mode you can specify it in the pyproject.toml file:

[tool.poetry.dependencies]
my-package = {path = "../my/path", develop = false}

Here I think that a command-line parameter would be more appropriate than a file parameter, as it is something that you want to configure at the command-line level rather than at the project level (like with pip where sometimes you want to run pip install . and sometimes pip install -e .). So if you could also drop the develop file parameter that would be awesome.

Being able to install projects in non-editable mode is so important, especially for deployment on servers. Currently we cannot use the poetry install command exclusively for such installations, we still have to resort to the pip install command.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[maggyero]

Up.

[cjolowicz]

This is an important feature for multi-stage Docker builds.

Multi-stage Docker builds for Python typically install the project into a virtualenv during the build stage, and then copy the virtualenv over into a slim final image. An editable install creates a .egg-link file that links to the source code, and this link would only be valid for the duration of the build stage.

Currently my build stage installs projects by exporting from Poetry to pip:

COPY pyproject.toml poetry.lock ./
RUN /root/.poetry/bin/poetry export -f requirements.txt | /venv/bin/pip install -r /dev/stdin 
COPY . ./
RUN /root/.poetry/bin/poetry build && /venv/bin/pip install dist/*.whl

The requested feature would allow us to use Poetry directly:

COPY pyproject.toml poetry.lock ./
RUN /root/.poetry/bin/poetry install --no-root
COPY . ./
RUN /root/.poetry/bin/poetry install --no-editable

[arbroen]

I am using the exact same scenario as @cjolowicz but with the added configuration of a private PIP server. I cannot use the PIP_EXTRA_INDEX_URL due to security issues and have this configured via the pyproject.yml instead. Thus the solution is:

RUN poetry install --no-dev
RUN rm .venv/lib/python3.7/site-packages/*.egg-link
RUN poetry build
RUN pip install dist/*.whl --target=.venv/lib/python3.7/site-packages/ --no-deps

A poetry install --no-dev --no-editable would be an improvement.

[maggyero]

@sdispater @finswimmer According to the number of thumbs up, this is an important feature. Being able to install projects in _non_ editable mode is so important. Without this, we cannot use poetry exclusively and still have to rely on pip (by calling pip install explicitly). Any chance this get prioritised?

[rainyday]

Currently the cleanest way I've found to do this is along the lines of

python3 -m venv /venv && \
. /venv/bin/activate && \
poetry install -n --no-dev --no-root && \
poetry build -f wheel -n && \
pip install --no-deps dist/*.whl && \
rm -rf dist *.egg-info

Adding this feature would cut the number of commands in half and I wouldn't have to worry about dist files getting left over in the event of a failure.

Edit: Actually, I realized you can use pip install --no-deps . (you can also skip --no-deps and install everything, though I'm not sure that uses poetry.lock so I'd avoid it) directly with newer versions of pip and it will pick up the configuration in the [build-system] section of pyproject.toml though this kept failing on my machine using pyenv. Worked in docker/when using system python, however.

[rainyday]

This is also an issue with path dependencies, which also only install as editable rather than actually installing to site packages, and seemingly aren't usable at all if you want pip compatibility. Unfortunately using git repositories isn't viable in a lot of situations. Most of the stuff I work on uses a chroot or container for the build process which has no access to the user's git credentials.

[thejcannon]

I'd like to see this feature for a reason I haven't seen enumerated yet. I can't validate my wheel has all the files I expect when I run my tests with my package in editable mode. Since the files will correctly be there locally, my tests pass, however it could very well be the case that I'm not including those files in my wheel meaning the package is broken.

My solution would be that PR validation would install the package in non-editable mode. Today that's accomplished by building the wheel and installing that, but would lovee to see poetry install --bikeshed "just work".

[finswimmer]

I can't validate my wheel has all the files I expect when I run my tests with my package in editable mode. Since the files will correctly be there locally, my tests pass, however it could very well be the case that I'm not including those files in my wheel meaning the package is broken.

@thejcannon Isn't this exactly why tox exists?

[thejcannon]

@finswimmer It may/may not be, but at this point tox is certainly more than that feature.

I hope you aren't advocating for a testing solution that involves both poetry and tox. They overlap in responsibilities (virtual environment management and command running), and I would much prefer to stay _just_ using poetry 😄 .

[ckp95]

I'd like to see this feature for a reason I haven't seen enumerated yet. I can't validate my wheel has all the files I expect when I run my tests with my package in editable mode. Since the files will correctly be there locally, my tests pass, however it could very well be the case that I'm not including those files in my wheel meaning the package is broken.

My solution would be that PR validation would install the package in non-editable mode. Today that's accomplished by building the wheel and installing that, but would lovee to see poetry install --bikeshed "just work".

Echoing this post -- today I couldn't figure out why my CI test for whether py.typed is included in the package wasn't working right. I have to use pip install . to make sure it's not in editable mode, but I'd like to be able to use Poetry instead.