Poetry: CLI proposal: Rename `develop` into `install`, remove `develop`

[moigagoo]

With the introduction of poetry develop, poetry install seems redundant. Both commands install the deps, but develop also makes the package importable from any script executed with poetry run. It seems install is just a worse version of develop now.

Making this change will simplify the CLI, reduce confusion (install command would install the package), all without breaking the current poetry install behavior.

[ambv]

I agree this would be cleaner.

[jacebrowning]

I also have a use case for poetry develop --no-dev. I want to be able to run a script on my build server that imports my package, but I don't want to waste time installing all the development dependencies.

Merging develop into install (and keeping --no-dev) would meet this requirement.

[moigagoo]

After having done some work with poetry develop, I propose an extension to the original proposition.

1. poetry install should install the dependencies and the package itself the regular, non-editable way. This way we guarantee that the package is installed and importable within the environment.

2. poetry develop should either install the deps and the package in editable mode, as it does now, or be removed in favor of poetry install --editable or poetry install --develop.

3. To preserve backward compatibility, a new flag --deps could be introduced to poetry install. With this flag, the command would act as it does now: install the deps but no the package.

Rationale

This proposition makes it possible for Poetry to work with namespace subpackages, which is currently impossible (at least I couldn't find the way).

Consider two projects: foo and foo.extension. They live in separate repos, the latter being a subpackage of the former.

In foo.extension project, you'd have foo as a dependency. poetry develop installs foo as a regular package but foo.extension in the editable mode. Because of that, foo.extension is inaccessible from foo. Installing foo.extension the regular way would copy its files into foo subdirectory, which would make it importable.

Concrete example: parent package Foliant has an extension Bump, which must be importable at runtime by Foliant in order to work.

With the currently available set of commands. I can't make the integration tests work, since foliant bump will not run as bump doesn't get added to foliant.cli during installation.

[jacebrowning]

I'm not too familiar with the internals.

Does the package have to be editable in order to import it from scripts? Are install and develop equivalent to the python setup.py <...> commands? Does the existence of *.egg-info necessarily mean the package was installed in an editable manner?

[moigagoo]

@jacebrowning No, the package doesn't have to be editable to be importable. It has to be installed or at least in sys.path.

Poetry's install and develop commands are equivalent to pip commands.

Yes, egg-info means the package was not actually installed i.e. copied to site-packages, but installed in editable mode, when only a link to the package gets added to site-packages.

Unfortunately, this method doesn't work for namespace packages. Also, Poetry doesn't provide a way to define namespace packages, but that's a different story.

[dfee]

I really don't understand the point of develop. Maybe 10 days ago the situation was different. But in my last 5 days of using this evolving tool, I cannot understand how poetry install is not a superset of poetry develop. What would be lost in straight up cutting poetry develop?

Next: poetry add vs poetry install.
The latter command – poetry install – installs the current directory. Whereas the former command – poetry add – adds a requirement to the pyproject.toml and then installs that package. See the confusion? The term install is overloaded.

But it kinda gets worse. If you want to install a package in development mode, you need to run two commands: poetry add --path ../mypkg mypkg and then poetry install --develop mypkg.

To that end, I think poetry add should not install a package, or it should allow the --develop option.

[jacebrowning]

@sdispater could you weight in on this proposal when you have time?

[cauebs]

I guess this can be closed now.
I'm not very happy with how the maintainer basically ignored this discussion. I get that it's _his_ project, but we're all here trying to improve it. It would be nice to just get some sign that actively thinking about these problems and stating our opinions isn't utterly pointless.

[sdispater]

@cauebs I'm sorry you feel that way. That was not my intention. Be assured that I value every feedback and I try to be as responsive as possible. So even though I do not necessarily respond it does not mean that I am not taking into account the feedback people are giving.

Specifically for this issue, the introduction of develop was a poorly though out idea and this issue made me aware of it. However, more important issues required my attention and, in the end, I put it on the backlog but I kept it in the back of my mind. And once the bulk of the work for release 0.12.0 was done I found the time to address this without notifying the participants and telling them that this concern had been heard and that it was being taken care of.

This is poor communication on my part, I agree, but rest assured that I welcome any discussion that can lead to improving Poetry.

[sdispater]

The install and develop commands have now been merged and develop is now deprecated.