Can we rename Cargo.toml?

[sinistersnare]

Hello, there has been a lot of discussion on the Cargo issue tracker about changing Cargo.toml to a more reasonable and precendent conforming name.

Possible solutions:

• Cargofile, also accepting cargofile (precedence from Makefile allowing makefile also)
• cargo.toml, precendece with setup.py and pom.xml

I think the only precedent I could find with Capital.ext is Setup.hs with Cabal in Haskell, but I have never used it, so I am not sure if this is true.

The original discussion on the issue tracker was almost unilaterally closed by wycats, and I would like to have an actual discussion, because most people on the tracker did not agree with the current convention.

[steveklabnik]

Other uses of capitals and File:

Berksfile Blakefile Cakefile Capfile Caskfile Cheffile Dockerfile Doxyfile Filefile Gemfile Gruntfile Guardfile Huxleyfile Jakefile Knylefile Makefile Modulefile Podfile Portfile Procfile Puppetfile Rakefile Sitefile Tenderfile Vagrantfile

That said, *file is terrible, it should have a real extension. I can’t find that blog post right now…

[sinistersnare]

Ok i agree, lets use an extension, which still leaves cargo.toml

[Ericson2314]

The more apt analog with Haskell is .cabal, which is not capital. The Setup.hs script is capital presumably because the convention for Haskell is to have capital module names and thus capital file names.

[ecl3ctic]

I’d prefer it to be lowercase to match existing conventions, for configuration files and Unix in general.

[DanielFath]

The problem is that Windows filesystem isn’t case sensitive. On Windows you could theoretically make cargo.toml and it could work on Windows, but fail on Linux. I think case insensitive cargo.toml would be best, with cargo.toml being the preferred form.

[killerswan]

Another alternative is .cargo.toml, so it would get hidden nicely sometimes.

[tbu]

That’s problematic for Windows users, it’s non-trivial to create a file with a leading dot if I remember correctly.

[arcto]

It’s intended to be edited manually, no? Then I don’t think it should be invisible.

[tbu]

.gitignore is invisible as well.

[DanielFath]

.gitignore is invisible as well.

And a pain in the butt to edit on Windows.

[arcto]

You’re right. Invisibility shouldn’t be a problem by itself. Please disregard that objection.

[tbu]

I was just responding to the invisibility (dot at the beginning) thing.

[DanielFath]

I didn’t consider it to be offensive. I was just remarking that I remember editing it on Windows. It’s not a happy experience (hence the comment). Searching for a tool that can make and/or change git settings was… Uegh.

[sinistersnare]

Can we agree on cargo.toml too then? invisibility is not what we want, and it follows conventions set by everyone else using the name.extension pattern.

Can someone tell wycats to comment on this?

[crazymykl]

For build systems, I still think Foofile is more common than foofile.foo, and I think its valuable to keep configuration for tooling seperate from configuration for the app itself (which is what I view the config dierctory as for).

[ruudva]

I’ve never really had problems with dotfiles on Windows. The only pain is that explorer does not allow you to name files starting with a dot, but it is fine from the command line. Microsoft’s own Team Foundation now even uses a .tfignore file, like .gitignore.

On topic: I’d prefer if lower case names were allowed in addition to capitalised.

[ecl3ctic]

FWIW I retract my original statement of support for a name change. It doesn’t really matter what the file is called. It’s really not going to cause any problems for anyone, any time, and there’s absolutely no benefit to trying to align it more closely with existing conventions.

Unless anyone can make an argument for how this will actually accomplish anything, I think we should probably just leave it.

[asb]

The reasoning is familiarity. There is a common convention for how these files are named (even better, two of them!), and Cargo chooses to follow neither making it much more likely people will get it wrong. It’s a minor issue, but it’s also pointless friction that could trivially be removed.

[ecl3ctic]

I don’t think that will ever be a real problem for anyone. People only have to manually edit the file once in a blue moon, and if they’re using a file browser, there’s no problem. If they’re using a terminal, they probably would ls anyway.