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

[nchammas]

• [x] 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?

[cauebs]

I think what you're looking for is poetry develop. Could you try it and see if it does the job?

[nchammas]

Oh, that does seem to work. 👏 Sorry, I missed that command!

What's the intended difference between poetry develop and poetry install --develop ...?

[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.

[tedmiston]

It seems that poetry develop has been deprecated since this thread.

$ poetry develop
develop is deprecated use install instead.
...

So maybe poetry install --develop=. is the right way to do this again now for developing a package and running it while you are developing?

[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.

[rendaw]

I updated to 1.0.9 and did poetry install and got a new line

 - Installing your-project (0.1.0)

and the scripts in tool.poetry.scripts appeared in PATH.

So I guess this functionality has been reinstated at some point.