Allow creation of "pre-install" script

[lilian-delouvy]

Issue Kind

Brand new capability

Description

It would be great for Poetry to allow developers to implement a "pre-install" script. As of now, the scripts of Poetry are available after running "poetry install" once. Sometimes, users will need to run a script before running "poetry install", as the example below shows.

Impact

In our company, we use local packages references like the following in a pyproject.toml: my_local_package = { path = "./packages/my_local_package", develop = true } But our local package is not actually in the given path : we have to copy it beforehand. We did this so that production packages are decoupled from other parts of the code and only code that is being actively used by our production packages are on our docker images. So we have something that looks like this:

• root_of_our_project
  • packages
    • local_package_A
    • local_package_B
    • local_package_C
  • production
    • production_package_A
      • src
        • <some_code_files_that_use_local_packages_A_and_C>
      • packages
        • local_package_A
        • local_package_C
    • production_package_B
      • src
        • <some_code_files_that_use_local_package_B>
      • packages
        • local_package_B

Therefore, a step that we have to do before doing "poetry install" on our production packages is to copy our local packages in the related "packages" folders via bash scripts.

It would be great to add a "pre-install" script implementation system so that we could just run "poetry install" and the copy of packages would be done under the hood before actually installing.

Workarounds

We currently run a bash file that will do the copy before doing "poetry install".

[dimbleby]

duplicate #2496

[lilian-delouvy]

@dimbleby I am not sure it is. If I'm not mistaken, PoeThePoet, and other elements discussed in #2496, describe scripts that would work after running "poetry install" at least once, which resolves dependencies and creates a virtual environment if necessary. I'm talking about a pre-install script, e.g a script that we could run right before the "poetry install" command, when the dependencies have not yet been resolved by Poetry. In my example, I believe the kind of scripts described in #2496 would not work, as the local packages would not have been processed yet.

[dimbleby]

yes, this is a duplicate.

eg one of the poe-the-poet examples is

tunnel     = { shell = "ssh -N -L 0.0.0.0:8080:$PROD:8080 $PROD &" }

[Alexdelia]

@dimbleby , I agree with @lilian-delouvy

take this situation

I only have poetry and git installed on my machine (no poe-the-poet, or any other tool) I want to clone a repository that has git hooks through pre-commit and do some dev work (note that poe-the-poet and pre-commit is in dev dependencies)

# pyproject.toml
[tool.poetry.group.dev.dependencies]
poethepoet = "*"
pre-commit = "*"

I would then

git clone [email protected]:Alexdelia/my_repo_that_use_poetry_and_pre_commit.git repo
cd repo
poetry install

but then, if I commit something, the git hooks won't be run, because poetry install did not run pre-commit install

you could say that I could use poe-the-poet to run the pre-commit job, but I cannot run poe-the-poet before doing poetry install as it's not installed on my machine

having one tool that manages all dependencies and workflow is very important and is missing in the python environment poetry is probably gonna solve this issue, but only if it implements all the necessary features

the node (javascript) environment has this solved:

# package.json
{
    "scripts": {
        "preinstall": "echo 'we gonna install!'",
        "prepare": "pre-commit install",
    }
}

you can find the docs for those hooks here: https://docs.npmjs.com/cli/v10/using-npm/scripts

[dimbleby]

(note that poe-the-poet and pre-commit is in dev dependencies)

this is not how that project asks you to install it https://poethepoet.natn.io/index.html#quick-start

... and this is anyway still a duplicate of other issues asking for the same thing

[Alexdelia]

this is not how that project asks you to install it https://poethepoet.natn.io/index.html#quick-start

don't you want to have to only use one tool to manage most of your workflow?

... and this is anyway still a duplicate of other issues asking for the same thing

and I don't see how the situation above can be solved with the current solutions

there are no hooks on install or any other events

[Alexdelia]

and I don't see how the situation above can be solved with the current solutions

there are no hooks on install or any other events

I would be happy to be proven wrong

[dimbleby]

don't you want to have to only use one tool to manage most of your workflow?

no, I really don't! (and if you have quibbles with the usage of poe the poet - please take them to that repository)

whether you see how this can be solved or not makes no difference to its status as a duplicate of #2496 etc

[Alexdelia]

I apologise, I did not realize that poe the poet handles poetry hooks

https://poethepoet.natn.io/poetry_plugin.html#hooking-into-poetry-commands

[bryant-finney]

@Alexdelia

I apologise, I did not realize that poe the poet handles poetry hooks

https://poethepoet.natn.io/poetry_plugin.html#hooking-into-poetry-commands

Great Scott! This solved my problem too. Thank you for pointing it out.

@dimbleby

... and this is anyway still a duplicate of other issues asking for the same thing

While I do agree that @nat-n's poethepoet provides a solution to both #9140 and #2496, it does so using two distinct features (to me, indicating that these issues are related but not duplicates).

In my circles, tooling sprawl is a common complaint about the Python ecosystem, and I too often compare poetry + poethepoet to yarn & npm when recommending them.

So I wonder: would either of the following strategies be a viable solution to both of these issues?

1. add language to the documentation that highlights poethepoet as one of poetry's missing batteries
2. implement a tighter integration between the two projects (such as defining poethepoet as a package extra, or even including it as a constraint)