an index of packages, not a sole package host. • Packages were often hosted elsewhere. • Ran on a single server in &, while serving the entire Python community. • Its use wasn’t a fraction of what it is today, so it wasn’t a problem.
good for automation. • Globally installed packages - impossible to have two versions of the same library installed. • People often just copied things into site-packages, manually. • Poor user experience.
• Mismatch: “What you want installed” vs “what you need” installed. • A pre-flattened dependency tree is required in order to establish deterministic builds. • Tools like pip-tools were created to ease this pain.
not the tool for building a library. • Pipenv update is really slow. • The dependency resolution will fail even if there is a solution. • Pipenv remote will not delete dependencies, only the package.
reaction to Pipenv issues. • Comes with exhaustive and fast dependency resolver. • Emphasis on semantic versioning and constraint specification (version “^1.4” instead of Pipenv “*”). • Easily build and package your projects: poetry publish.
reaction to Pipenv issues. • Comes with exhaustive and fast dependency resolver. • Emphasis on semantic versioning and constraint specification (version “^1.4” instead of Pipenv “*”). • Easily build and package your projects: poetry publish.
Poetry • Already with Pipenv? Stay on it! • Be patient and wait for native support in Pip and Python PEP518 Specifying Minimum Build System Requirements for Python Projects PEP517 A build-system independent format for source trees