Hacker News Reader

Comment by witten | Hacker News Reader

I'm not sure age is a good indication of goodness in this regard. Python has been doing setup.py for much longer than 7 years. It's a similar format, and ripe for abuse because you have full access to a general purpose programming language in it. I've seen setup.pys call out to Inkscape. I don't want a general purpose programming language in my requirements.txt (or equivalent). I want a dumb declarative data file.

Also, I'm not sure how a lock file in source control will help me when someone who is not checking out source wants to pip install my project using said lock file.

View on HN

Age is a good indication if there were serious issues with this approach we would have found them.

There seem to be a lot of strange fears from python developers about this approach and my comment on age was an attempt to assuage those fears. Since ruby developers are quite happy with bundler (at least in comparison to other communities) and have been for some time it's a reasonable point and not the only one I made.

I'm not sure how pip plans to use the lock file for projects distributed via pip. They may very well have a solution planned for that.

However, for projects that are distributed by source (which are many) the lock file ensures deterministic builds, and requirements.txt generally doesn't without being pedantic with your versions.

> There seem to be a lot of strange fears from python developers

There you go again.

This isn't fear. It's asking the question of: What. Is. The Damn. Point. Of. This?

I have yet to see a simple, cogent explanation of why this is better than a list of requirements specifying;

pyside==x.y.z

pillow==x.y.z

As opposed to this proposed Thing.

You know what this reminds of?

It reminds me of replacing super simple .INI text files with configuration files stored as XML - change for the sake of it, because Change!

Now, I'd love to see a very simple explanation and justification on why we should all move to this new Thing you're making.

Something like "This new Thing is better because..." , followed by practical /examples/ , because right now, all I see is More Complicated Stuff For The Sake Of It.

There were clear fears/risks/concerns stated by witten directly above. I didn't invent the idea of fears being stated out of whole cloth.

> subject to all the abuse you can introduce

> might cause [...] problems

I've said a few things about the potential benefits, though I am not involved in the project. The actual authors offer the best list of benefits: https://github.com/pypa/pipfile#the-concept

They also point out this will eventually be built into pip, so it will have the benefits of all the existing workarounds like pip-tools without any setup. It does seem like a lot more than change for the sake of change, and along with it since there is so much change why not take the opportunity to adopt a flexible DSL built for future extension so there is less real change in the future.

One thing I learned yesterday was that requirements.txt supports conditionals like

    SomeProject==5.4; python_version < '2.7'
    SomeProject; sys.platform == 'win32'

In my view, that's already out of hand, and isn't even really parsable without some bespoke library.

I'm a big fan of this idea of having a requirements.lock. I can call pip to do the parsing, then I can parse the lock which is just json.

The fact that you need to parse the requirements.txt feels like a design issue with pip to me. (Of course, I'm coming from Rubyland.) As for setup.py, setup.py is broken because it conflates build scripting with package metadata and dependencies. Now that tox exists things are better (but the fact that tox is not a general-purpose programming language is IMO unfortunate coming from Rake/Ruby/Bundler/Gemfiles.)

Reply on news.ycombinator.com