Hacker News Reader

Comment by yladiz | Hacker News Reader

Sure that happens, but is it worth the hassle of having to type -p or -r requirements.txt every time you want to install the requirements for your project? Following that dogma without regard for the reality of what actually works better is silly. It's not always the case that doing what everyone else does is good, but it seems the consensus is have sensible defaults.

This is a similar argument to what happened when Babel in JS land decided to not have anything happen by default and explicitly require you to decide your configuration. It's silly to force users to do something that could be solved by a sensible default, and this is a clear case where a sensible default is appropriate.

View on HN

I agree that explicit is better than implicit. Especially in this case. You can create an alias pipr='pip install -r requirements.txt' or similar if you find that fits your needs better.

Especially for newcomers, an implicit "use Pipfile if exists, else requirements.txt" is just unnecessary magic.

`pip install` should only be for the default way that projects define dependencies, where the default is the way. Were we to have both pipfile, and requirements.txt, and maybe a third, and a fourth option, I don't think `pip install` should work.

I also don't think it's ever a good idea to have multiple options for something like that.

The hassle of typing three characters? Yes it is worth the hassle of not accidentally installing things that aren't specified.

Dear god we love to bikeshed.

It's not bike shedding, it's a valid concern: either I type it infrequently enough that I will probably forget, meaning I'll have to either remember after I type it incorrectly the first time or look on Google, or I type it frequently enough that it actually does affect my productivity. In my eyes, having no default and forcing users to type in something like -r requirements.txt or -p is just forcing users to do something that can be sensibly defaulted and wasting their time. It's like in an elevator, are you expected to close the door by pressing the close door button every time, or open the door when you arrive to the floor? No, because the elevator manufacturer knows getting in an elevator and pressing a floor button means you want the door to close and open for you. The same can be said about pip install: if a requirements file (requirements.txt, Pipfile) exists, and the user types in pip install, it's simple enough to infer that the user wants to install based on the installation file parameters. What's wrong with that inference? Dogma?

An elevator door must always be closed prior to going up or down in a building. Pip will sometimes install from Pipfile, sometimes from requirements, sometimes from another command line argument. What if both Pipfile & requirements.txt exist?

Requiring a user to say what they want from a command line tool (that takes barely two seconds to type) is hardly an exhausting task.

Absolutely. If it does the wrong thing, e.g. by doing that outside a virtualenv, I'd very much prefer it to not destroy my global environment. Or if you have different .txt files for different purposes, I'd rather not destroy the virtualenv by adding / changing packages by accident.

Besides. Tab completion. And if it's really that important, make an `alias pipi="pip install -r requirements.txt"`.

Is it so much trouble? How often do you type 'pip install -r requirements.txt' outside of a script?

Personally, I'm in the "whatever" camp. But you can be certain that such a change will break something.

For me it's more about encouraging good behavior. While it's common to pip install random packages, that should really be the exception rather than the rule. Usually you should make a project, add some packages, and run `pip install`.

Right now, the whole system encourages you to build bespoke environments that are really difficult to replicate. Making the default use requirements.txt encourages you to write down everything you're doing in a reproducible way.

> write down everything you're doing in a reproducible way

Making `pip install` context-sensitive (dependent on the current working directory) would reduce reproducibility. Imagine the instructions to a beginner: (1) download, (2) cd, (3) pip install. Many times the beginner will skip step 2 or accidentally wind up in the wrong directory.

I really think the average beginner is not somebody who knows nothing about packaging, but someone like me who knows a lot about other packaging systems. When I started with pip a few months ago, everything was confusing, largely because pip has confusing conventions that don't match tools like bundler, cargo, and npm that I'm more familiar with.

I do think you're misrepresenting the instructions to the beginner. The instructions to the beginner are (1) download (2) cd (3) run tox.

Beginners shouldn't even need to know what pip is, tox (or another build tool) should handle everything for you.

> The average beginner is ... someone like me

When I say "beginner" I mean someone who is learning their first programming language and may have never opened Terminal or `cmd.exe` before.

> run tox

I thought the argument above was that the command should be `pip install`. This is confusing.

> Beginners shouldn't even need to know what pip is

Ok, in that case, why do you care whether `pip install` has an implicit default mode?

My preference would be that pip install only has one mode. Realistically, there is going to be backwards compatibility stuff, but ideally, even in advanced use you should never have a reason to use anything other than pip install, and the rest should be specified in config files.

You could write a make file that does the install. That'd solve the one-command desire.

Reply on news.ycombinator.com