Please consider lowercase: pipfile and pipfile.lock
Closed this issue · 11 comments
Is there a good reason why Pipfile{,.lock} couldn't be all lowercase? It sucks to have to hit the SHIFT-key when using the commandline, IMHO. At least, please consider accepting both pipfile and Pipfile.
Pipfile (a file) isn't meant to be run as a script. Why would you want to use it in a commandline?
Pipfile (a file) isn't meant to be run as a script. Why would you want to use it in a commandline?
$ vi Pipfile
Oh, makes sense.
Just for the reference, here's what make(1) says about [Mm]akefile:
make executes commands in the makefile to update one or more target names, where name is typically a program. If no -f option is present, make will look for the makefiles GNUmakefile, makefile, and Makefile, in that order.
Normally you should call your makefile either makefile or Makefile. (We recommend Makefile because it appears prominently near the beginning of a directory listing, right near other important files such as README.) The first name checked, GNUmakefile, is not recommended for most makefiles. You should use this name if you have a makefile that is specific to GNU make, and will not be understood by other versions of make.
At this point it seems like a pretty common convention. Makefile, Vagrantfile, Dockerfile, and most similarly Gemfile. I think having Pipfile with a capital P makes sense - if you don't like hitting shift, that's more of a personal preference, and there are options to customize your terminal to make tab completion case-insensitive.
@monkpit please notice the order of preference for make. Having pipfile ignore the case out of the box would not harm those who swear by capitalization and would help those who don't.
@dstufft or @kennethreitz - Could one of you say what you think about this?
AFAICS, it's going to be pretty easy (and transparent) to support the lower case variant with Pipfile taking higher precedence than pipfile.
I don't see any reason not to support the lower case variants, we wouldn't combine them, we'd just use the first one we found.
I think having one obvious way to do it is the best path moving forward, e.g. just supporting one filename, but once this library gets more robust, it'll be easier to support other filenames.
Closing for now — will definitely keep this in mind for the future.