[Feature] Poetry needs a reproducible install for itself

[awilkins]

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

Feature Request

When installed, Poetry installs the latest available versions of packages in it's dependency graph.

This has lead to multiple occasions where even when installing a specific version of the Poetry client, differences in the installed libraries have lead to an inconsistent experience.

• e.g. Poetry refuses to install package with correct hash #4523
  • which was caused by ongoing releases in poetry-core deprecating support for md5 hashes
• e.g. "Unable to find installation candidates for" packages cached from a LegacyRepository (/simple) #4688
  • which was caused by an update to cachecontrol

It's quite ironic for a tool which promotes reproducible builds through the use of a lockfile that it should suffer from breakages caused by installing itself via pip.

Given the purpose of Poetry (and poetry-core), it's very likely to be installed and used in a CI pipeline, where stability and reliability are strong concerns. I humbly submit that installing Poetry and poetry-core should be a reproducible act for a given version number.

Suggest that this may be achievable by (preferring the first)

• Having a poetry build mode that outputs a setup.py with frozen dependency specifications based on the lock file
  • and using this mode for subsequent releases of poetry and poetry-core
• Using the output of pip freeze for install-poetry.py instead of

        if self._git:
            specification = "git+" + version
        elif self._path:
            specification = version
        else:
            specification = f"poetry=={version}"

        subprocess.run(
            [str(python), "-m", "pip", "install", specification],

[finswimmer]

Hello @awilkins,

the recommended installation method for poetry is the install-poetry.py or get-poetry.py install script. Both make use of the lock file.

fin swimmer

[awilkins]

Both make use of the lock file.

I pulled install-poetry.py today. I think this is the relevant function.

    def install_poetry(self, version: str, env_path: Path) -> None:
        self._overwrite(
            "Installing {} ({}): {}".format(
                colorize("info", "Poetry"),
                colorize("b", version),
                colorize("comment", "Installing Poetry"),
            )
        )

        if WINDOWS:
            python = env_path.joinpath("Scripts/python.exe")
        else:
            python = env_path.joinpath("bin/python")

        if self._git:
            specification = "git+" + version
        elif self._path:
            specification = version
        else:
            specification = f"poetry=={version}"

        subprocess.run(
            [str(python), "-m", "pip", "install", specification],
            stdout=subprocess.PIPE,
            stderr=subprocess.STDOUT,
            check=True,
        )

Could you point out where it makes use of the lockfile here, because I'm not seeing it? Is this the wrong routine?

[finswimmer]

Ah, sorry. Looks like a was to fast with my answer (shouldn't answer during my vacation 😄)

Pinning of the dependency was done by vendoring when using the get-poetry. py script.

With the new installer script we do not vendor the dependencies anymore. Taking the lock file into account is also not possible during installation, because this would require to have poetry installed.

[tom-bowles]

We deploy our poetry-developed applications by first installing a requirements.txt that we generate from the lock file using poetry export. Then we install the wheel. This gives us dependencies that match the lock file without requiring poetry on the deployment machine.

I am in the process of writing a custom install script for the users I support that does the same thing for poetry itself, because we have no choice but to pin both poetry and poetry-core due to a series of releases that are severely broken on Windows (please could somebody give my one-line PR #4682 some love?). Until I complete this custom script, our poetry installation process is to:

• Use install-poetry.py with the --version parameter to install version 1.1.6
• Use pip3.exe from in poetry's venv to --force-reinstall poetry-core to version 1.0.4

Requirements.txt based pinning of dependencies in the installer would be awesome. An alternative (not saying if it's necessarily better) would be to implement the feature discussed in #2778 and use it for poetry itself.