1. 13

Pasted from the README:

Warning: this project is under active development.

A Pipfile will be superior to a requirements.txt file in a number of ways:

  • Expressive Python syntax for declaring all types of Python
  • Grouping of sub-dependency groups (e.g. a testing group).
  • Use of a single file only will be extremely encouraged.
  • Pipfile.lock
  1.  

  2. 5

    It strikes me as odd that nowhere in the project is “Gemfile” or “bundle” or “ruby” mentioned. Is this not directly inspired by bundler?

    1. 5

      The Basic Concept Gist linked from the readme has a mention of “simple.crate.io”, which leads me to suspect this is at least partially inspired by Rust’s package-manager Cargo.

      Cargo was inspired by Bundler, and I believe Mozilla even contracted some of the people who wrote Bundler to write Cargo, so there’s definitely a design heritage there, but obscure enough that it’s not called out particularly.

      It’s no longer “the way bundler does it”, it’s now “the way all sensible package-managers do it” — Bundler, Cargo, Yarn, and (apparently) soon Pip.

      1. 5

        Yes, the original builders of Bundler, Yehuda and Carl, wrote the initial implementation of Cargo.

      2. 1

        Only so much as it was inspired by “Dockerfile”, “Procfile”, “Makefile”, “Drakefile”, etc. I’m not sure it matters which came first anymore.

        1. 2

          I expected mention of bundler because of the presence of the “.lock” file more than what the main filename is. AFAIK bundler was the first package manager to make use of the “lockfile” concept, which then was also built in to cargo, the package manager for rust, composer, the pm for PHP, the new pm for javascript yarn, etc.

      3. 2

        Does this let me get rid of setup.py? I don’t think it does, because it seems to be missing an awful lot of functionality (e.g., about what source I’m distributing and what extra files to include). Since I’ll need setup.py anyway, this doesn’t feel terribly useful.

        1. 4

          A good chunk of the data in setup.py can also be specfied (statically) in setup.cfg.

          Information about what extra files to include can be specified (statically) in MANIFEST.in.

          The PyPA folks are very slowly and carefully building a useful, modern packaging system on top of/beside the accumulated decades of cruft of Python’s packaging tools. I’m not sure where they’re headed, ultimately, but they’re showing such good taste and responsible caution in all the changes they’ve made so far, I’m inclined to trust them for the rest.

          1. 1

            I hope you’re right, and I hope we can get a one-stop-shop config file for all of our packaging needs. I still need to lookup whether distutils or setuptools or whatever is the one to actually use.

            1. 1

              For a while now, Pip jumps through hoops to ensure that every setup.py is run with setuptools, even the ones that don’t explicitly import it. So right now, Python packaging is 100% setuptools, all the time.

          2. 2

            Indeed. Unless I’m missing something now we’re going to have even more confusion with what to use to specify dependencies of a library. There’s setup.py/install_requires which doesn’t support SCM paths and there’s pipfile which looks deceptively more useful than requirements.txt, but still lacks the rest of the metadata from setup.py.

          3. 2

            A Pipfile will be superior to a requirements.txt file in a number of ways:

            • Expressive Python syntax for declaring all types of Python dependencies.

            As far as I can tell, it is undecided whether this will by Python-like or full Python. Full Python is terrifying. Having configurations in a full language means that packages you depend on can do all kinds of things leading to nondeterminism. Can you make network calls to determine what the requirements are? Read from disk? Read the time? Read your current OS? Write to disk?

            In a full language, the inputs to the dependency calculation are basically unrestricted. This is a nightmare for packagers, as there’s no way to ‘fake’ another environment if you want to, say, make a Windows package on Linux. I hope they stick with a restricted, Python-like syntax.