pypa/pipfile

consider: please change the names of these files

Closed this issue · 14 comments

glyph commented

Rather than naming it "Pipfile.lock", could we call these something else before they catch on?

  1. File extensions are a good idea; Filefiles are an antipattern. This new file should be <something>.pipfile. Lots of software (the mac's Finder, windows's Explorer, Nautilus, Vim, Emacs, Apache, Nginx, anything that knows how to read /etc/mime.types) can infer a MIME type from an extension easily and only from a full filename with great difficulty if at all. Even if it's always called Pipfile.pipfile, please consider a unique file extension.
  2. A file whose name ends in .lock is a file that you call flock() on, or perhaps, over NFS, that you call open(..., O_CREAT | O_EXCL) on. In other words, it is a lock. I realize that this naming convention is sort of by extension to Ruby's Gemfile.lock, but (A) the contents of the file are of a different MIME type than Gemfile.lock so it should be a different extension, and (B) Gemfile.lock is one of the worst, most baffling names ever given to an abstraction. Other suggestions: KnownGood.pipfile, ExactVersions.pipfile, Complete.pipfile, Exhaustive.pipfile, Repeatable.pipfile...?

Don't get me wrong - this is extremely useful functionality and I'm looking forward to using it! I just really hope that we can avoid repeating a templated set of mistakes that many programming tools seem intent on promoting these days.

sethmlarson commented

I agree that the .lock extension is especially awkward.

jacebrowning commented

What about requirements.pip and requirements.piplock?

  • ❤️3
Tatsh commented

I say since Pipfile is Python code, then it should just end in .py. And similarly, use .json on the lock file. I don't see a reason to avoid the generic extensions. You could even use .lock.json.

.lock.json has no real precedence, but using the generic extension does: composer.json, package.json.

├── pip.py
├── pip.lock.json
└── setup.py
  • 👍1
  • 👎2
ryneeverett commented

Can't we avoid an overloaded term like "lock" altogether? How about Pipfile.freeze?

  • ❤️5
kennethreitz commented

@jacebrowning i love your recommendation, and may use these names. @glyph, I was generally opposed to your feedback until I saw these name suggestions. I think they're great.

  • ❤️4
kennethreitz commented

@jacebrowning your feedback has been incorporated into the document.

@ryneeverett I like the idea of requiments.pip and requirements.freeze as well. I will heavily consider that.

  • ❤️2
glyph commented

@kennethreitz I should have been clearer that my extension suggestions were somewhat intentional strawmen. I'm glad that others stepped up and came up with better names!

  • 👍3
reillysiemens commented

FWIW, requirements.pip and requirements.freeze seem like much better names to me! Thanks @glyph, @jacebrowning, and @ryneeverett!

  • ❤️1
kennethreitz commented
dstufft commented

I think that requirements.pip is a non-starter, since it's in common use today for what currently exists. I also don't think that Filefile is an antipattern, they've existed since the 1970's, if software can't handle them by now then maybe that software is just bad.

  • ❤️1
kennethreitz commented

Updated to Pipfile and Pipfile.freeze in 15a1f0d

  • 👍2
sethmlarson commented

As long as the .lock extension was done away with I am fine with any decision. :) Completely agree with Pipfile and Pipfile.freeze.

  • 👍2
  • ❤️1
dstufft commented

I don't have an opinion on .lock vs .freeze, so I'm fine with either.

sethmlarson commented

@dstufft .lock just makes me scared to delete it because it makes me think that another process is using it as a file mutex or something. Having .freeze makes me feel a lot more safe in deleting it. I think this thought is shared by more than me?

  • 👍3