4 ms·

I'm afraid I never saw what was wrong with specifying dependencies in setup.py. For me, having requirements.txt and setup.py is confusing. Can't we just stick w

by tlocke 10y ago

I'm afraid I never saw what was wrong with specifying dependencies in setup.py. For me, having requirements.txt and setup.py is confusing. Can't we just stick with setup.py? (and yes, I've read Donald Stufft's post https://caremad.io/posts/2013/07/setup-vs-requirement/ https://caremad.io/posts/2013/07/setup-vs-requirement/ and remain unconvinced).

sambe 10y ago
I best way this was explained to me was to keep your unversioned dependencies in setup.py and keep developing and testing against latest. Then when you release, requirements.txt should be a result of the build (not an input) which says "these versions work, this is how you install this release". It makes more sense for an application than for a library, but I think making that the primary distinction only adds confusion. All that said, I have no clue what Pipfile is adding. The rationale appears to be that people sometimes don't use requirements.txt properly? Can one of the very enthusiastic commentators explain their enthusiasm?
Sean1708 10y ago
And since this Pipfile is just a bunch of function calls, why can't it just be put in setup.py? Or is the idea to eventually get rid of setup.py?
- nchammas 10y ago
  > And since this Pipfile is just a bunch of function calls That hasn't been settled yet. It's being actively discussed [0]. > Or is the idea to eventually get rid of setup.py? Yes, a replacement for setup.py has already been agreed on in PEP 518 [1]. It's called pyproject.toml. [0] https://github.com/pypa/pipfile/issues/10 https://github.com/pypa/pipfile/issues/10 [1] https://www.python.org/dev/peps/pep-0518/ https://www.python.org/dev/peps/pep-0518/
  - theptip 10y ago
    That PEP leads down an interesting path -- hadn't realized there was a completely new packaging tool called "flit" that's aiming to be much more lightweight than setuptools. https://pypi.python.org/pypi/flit https://pypi.python.org/pypi/flit Looks quite nice, a flat .ini file for specifying deps, though it only builds wheels.
nchammas 10y ago
The section titled "So Why Does Abstract and Concrete Matter?" on Donald's post explains pretty clearly why you can't have these two types of dependencies in the same file. There is another discussion on the Pipfile repo about this that may also clarify things for you [0]. The example I posted there [1], which I'll post again here, is: --- A project can only have 1 set of abstract dependencies (setup.py/pyproject.toml), but different users working with that project can have different sets of concrete dependencies (requirements.txt/Pipfile) which allow them to fulfill those abstract dependencies from PyPI mirrors, private package indexes, personal forks on GitHub, or somewhere else. So if project Car depends on Engine (an abstract dependency), I can choose to install Car but grab Engine specifically from a fork I made on GitHub (a concrete dependency) that has some performance improvements. Meanwhile, someone else working at a big company that doesn't want to depend on external services to build and deploy their internal Python projects can choose to install both Car and Engine from their private package index as opposed to PyPI (another concrete dependency). You can't merge these two types of dependencies together into one file without hampering people's ability to choose where to get their dependencies from. --- According to another commenter on that issue [2], both Rust and Ruby have a similar split in how they specify dependencies. [0] https://github.com/pypa/pipfile/issues/27 https://github.com/pypa/pipfile/issues/27 [1] https://github.com/pypa/pipfile/issues/27#issuecomment-262289776 https://github.com/pypa/pipfile/issues/27#issuecomment-26228... [2] https://github.com/pypa/pipfile/issues/27#issuecomment-262264222 https://github.com/pypa/pipfile/issues/27#issuecomment-26226...

by tlocke 10y ago

sambe 10y ago

I best way this was explained to me was to keep your unversioned dependencies in setup.py and keep developing and testing against latest. Then when you release, requirements.txt should be a result of the build (not an input) which says "these versions work, this is how you install this release". It makes more sense for an application than for a library, but I think making that the primary distinction only adds confusion. All that said, I have no clue what Pipfile is adding. The rationale appears to be that people sometimes don't use requirements.txt properly? Can one of the very enthusiastic commentators explain their enthusiasm?

Sean1708 10y ago

And since this Pipfile is just a bunch of function calls, why can't it just be put in setup.py? Or is the idea to eventually get rid of setup.py?

nchammas 10y ago
> And since this Pipfile is just a bunch of function calls That hasn't been settled yet. It's being actively discussed [0]. > Or is the idea to eventually get rid of setup.py? Yes, a replacement for setup.py has already been agreed on in PEP 518 [1]. It's called pyproject.toml. [0] https://github.com/pypa/pipfile/issues/10 https://github.com/pypa/pipfile/issues/10 [1] https://www.python.org/dev/peps/pep-0518/ https://www.python.org/dev/peps/pep-0518/
- theptip 10y ago
  That PEP leads down an interesting path -- hadn't realized there was a completely new packaging tool called "flit" that's aiming to be much more lightweight than setuptools. https://pypi.python.org/pypi/flit https://pypi.python.org/pypi/flit Looks quite nice, a flat .ini file for specifying deps, though it only builds wheels.

nchammas 10y ago

The section titled "So Why Does Abstract and Concrete Matter?" on Donald's post explains pretty clearly why you can't have these two types of dependencies in the same file. There is another discussion on the Pipfile repo about this that may also clarify things for you [0]. The example I posted there [1], which I'll post again here, is: --- A project can only have 1 set of abstract dependencies (setup.py/pyproject.toml), but different users working with that project can have different sets of concrete dependencies (requirements.txt/Pipfile) which allow them to fulfill those abstract dependencies from PyPI mirrors, private package indexes, personal forks on GitHub, or somewhere else. So if project Car depends on Engine (an abstract dependency), I can choose to install Car but grab Engine specifically from a fork I made on GitHub (a concrete dependency) that has some performance improvements. Meanwhile, someone else working at a big company that doesn't want to depend on external services to build and deploy their internal Python projects can choose to install both Car and Engine from their private package index as opposed to PyPI (another concrete dependency). You can't merge these two types of dependencies together into one file without hampering people's ability to choose where to get their dependencies from. --- According to another commenter on that issue [2], both Rust and Ruby have a similar split in how they specify dependencies. [0] https://github.com/pypa/pipfile/issues/27 https://github.com/pypa/pipfile/issues/27 [1] https://github.com/pypa/pipfile/issues/27#issuecomment-262289776 https://github.com/pypa/pipfile/issues/27#issuecomment-26228... [2] https://github.com/pypa/pipfile/issues/27#issuecomment-262264222 https://github.com/pypa/pipfile/issues/27#issuecomment-26226...