`poetry install` should make console script entry points available on the current PATH

• I have searched the issues of this repo and believe that this is not a duplicate.

This issue is related to #34 and #149, and may in fact be a duplicate of #149, but I’m not sure.

Issue

I’m currently test-driving Poetry with my project, Flintrock.

Flintrock is a command-line tool for managing Apache Spark clusters on EC2. As such, I have a bunch of acceptance tests that actually run Flintrock and manipulate real resources on EC2 to confirm that things are working as expected. It’s not the best system – the tests are slow and cost money – but they work for me and are an excellent way to test a tool like Flintrock. The acceptance tests call Flintrock using subprocess.run() and thus expect flintrock to be on the PATH.

I have this setup working fine with my current workflow involving setuptools, a console_scripts entry point, and pip install -e .. However, it seems that this workflow will not translate seamlessly to Poetry, as explained in #34 and #149.

Specifically, when I run poetry install, it does not place flintrock (which is defined via tool.poetry.scripts) on my PATH. Spawning a shell via poetry shell still does not get me flintrock on my PATH. poetry install --develop flintrock is the same.

It appears that as of Poetry 0.11.2, my only option is to call poetry run flintrock if I want to access that console script.

This has a couple of implications:

1. I can no longer interactively run flintrock ... as I’m experimenting with changes. I now have to preface every invocation with poetry run flintrock ....
2. I have to update my acceptance tests to either use the poetry run flintrock ... invocation, or I need to update them to not use the console script at all and just call the underlying Python function.

This is not a huge deal, and indeed I feel it is fair game to expect some workflow changes when migrating to a whole new way of packaging and publishing your projects. But I still feel it would be better if poetry install worked such that I didn’t have to change my workflow–i.e. it would place flintrock on my PATH when I have a virtual environment activated (either via poetry shell or because I manually activated one).

I wish I could express more clearly why, but it somehow feels more “correct” if Poetry were to directly expose features like console script entry points within the neat scope of a virtual environment, as opposed to cordoning them off behind poetry run. And it would certainly remove a point of friction for people migrating existing projects from setuptools to Poetry.

What are your thoughts on modifying poetry install as described here?

[mcouthon]

poetry install --develop doesn’t exist either, so I’m not sure how to solve this right now, outside of being forced to use poetry run.

[nchammas]

Closing this issue since poetry develop does what I need, but it might be helpful to clarify the difference between that and poetry install --develop somewhere.