Manim: Naming convention for config files

Created on 8 Jul 2020  路  16Comments  路  Source: ManimCommunity/manim

As it stands right now the code looks for a
.manim.cfg in the user directory, and a
manim.cfg in the current working directory.
Note the difference in the leading dot.

The initial reason for this was the convention to hide configuration files that go in the user directory, which is far as I get is only a Linux relevant convention, since Windows uses file attributes to hide files, not leading dots.

I'm opposed to this mixed naming for two reasons.

  1. The smaller reason is copypastability, as like this either file could almost directly be used as a template for the other, but with the additional hoop of having to add/remove a dot.
  2. The bigger reason is the potential for confusion. Having the naming convention differ in just one character, and a dot at that, is a sure fire recipe for some people to forget this small difference at times, leading to wrongly named and hence not working config files, or even completely missing that difference in the first place, since it's easy to miss the addition/subtraction of a dot on a file name when already primed for one or the other convention.
    Point in case, despite carefully reading @leotrs post in #178 2 mentions of .manim.cfg made me completely miss that on the third time it was intentionally manim.cfg.

With that said I have no strong opinion on what the convention is, so long as it is consistent. With dot, without, or accepting with/without in both places are all fine.

Probably allowing both presence and lack of a leading dot is the best approach simply to allow Linux users to hide their config files or not while also making sure that config files can't that easily be misnamed.

cleaning enhancement

Most helpful comment

For Windows that'd most likely be %appdata%, which means:
\[Username]\AppData\Roaming\
And then to be specific:
\[Username]\AppData\Roaming\Manim\manim.cfg

In this case AppData is the hidden folder. And now that you made me think of it... very yes. Although newbie users might not know about the AppData folder, it's indeed were programs should store their configuration, so that migrating it to a different machine/user makes all of the programs using it behave the same.
I'm in favor of this too then as it would definitely be good practice, now we're just missing the according place for Mac.

All 16 comments

I agree this should change. Thanks for bringing it up. My idea is to use manim.cfg for all files across all platforms. What should be changed is the location of those files. Currently, we just put that file in the user's home folder. But it can change from platform to platform. For example, another usual place for Linux is to put it inside /home/some_username/.config/manim/manim.cfg. Are there similar user-wide config folders on Windows or Mac?

For Windows that'd most likely be %appdata%, which means:
\[Username]\AppData\Roaming\
And then to be specific:
\[Username]\AppData\Roaming\Manim\manim.cfg

In this case AppData is the hidden folder. And now that you made me think of it... very yes. Although newbie users might not know about the AppData folder, it's indeed were programs should store their configuration, so that migrating it to a different machine/user makes all of the programs using it behave the same.
I'm in favor of this too then as it would definitely be good practice, now we're just missing the according place for Mac.

Are there similar user-wide config folders on Windows or Mac?

For macOS, the location ~/Library/Application Support/ would be a suitable place.

The final location would look something like ~/Library/Application Support/Manim/manim.cfg

Excellent! Anyone volunteer a PR? :)

Well, with this being a thing that reaches across all of the OSes and has to be tested on all of them, what we should probably do is someone making a branch that replaces os.path.expanduser('~/.manim.cfg') with a variable set with an OS check, then have 2 other people join this branch and add the stuff that works on their OS, then once the branch works for all of us we can make the PR.
I can join and make sure it works on Windows, but have no idea about OS check best practices, so won't be the one to start it up. There's this weird current_os.startswith("CYGWIN"): in __main__.py and I have no idea what that's all about or if it's relevant.

Btw, it would be extremely convenient if we could add something like a CLI flag that opens the associated correct user config file (and also creates it if it doesn't exist) using the same path creating logic that later reads it out.

There's this weird current_os.startswith("CYGWIN"): in __main__.py and I have no idea what that's all about or if it's relevant.

"Cygwin is a POSIX-compatible programming and runtime environment that runs natively on Microsoft Windows". It's a way of emulating(?)/developing(?)/compiling(?) ... erhm _running_ ... things on Windows that were meant to be for POSIX systems such as Linux.

Btw, it would be extremely convenient if we could add something like a CLI flag that opens the associated correct user config file (and also creates it if it doesn't exist) using the same path creating logic that later reads it out.

What do you mean by "open" here? Right now whenever you run manim it will output to console the paths of the config files that were loaded. So everytime you run it you can see the paths of all config files found. We can also implement something like manim cfg-files to show only the paths without having to render any scenes. Or even something like manim cfg-show that shows the final, actual config dictionary that includes all config files found. (This would be useful because of the cascading system. No single file is going to contain the actual final dictionary because they all override each other.) Is this what you meant?

"Cygwin is a POSIX-compatible programming and runtime environment...

Right, I've been roughly aware of that, but I don't know what it means for file handling. Would Cygwin actually behave all the same as being run in a standard Windows CLI or not?

What do you mean by "open" here?...

Right, I suppose those would be useful but that's not what I mean. I just mean a CLI flag that would create the user config file if it doesn't exist, and then _open_ it. As in running it, showing it in some associated program, so that the user can edit it. As the -p flag currently does for finished files. As opposed to digging your way to the folder location manually.

I just mean a CLI flag that would create the user config file if it doesn't exist, and then open it. As in running it, showing it in some associated program, so that the user can edit it. As the -p flag currently does for finished files. As opposed to digging your way to the folder location manually.

Agreed (this is what I meat above by manim cfg-show. This is a good idea in general. (I don't like the idea of opening it as opposed to just printing on screen, but that's another conversation.) Tagging @eulertour for thoughts. Ties in with #151 @Aathish04

Also, @XorUnison could you please open a different issue for that? (EDIT: nvm just did it myself, #201 ) Let's keep this one for discussing the naming convention for config files.

@XorUnison Do check #151 , I have implemented your Idea.

@XorUnison Do check #151 , I have implemented your Idea.

Took me a while to find it but it looks good so far. I tried it with the shorter os.path.expandvars("%appdata%\Manim\manim.cfg") but I assume your code does about the same. Does it still need to be actually tested on Windows?

No, I myself have tested it on Windows. So, no problem.

I've been having second thoughts about using ~/Library/Application Support/Manim/ as the home of the user-wide MacOS config file.

I mean, while it _is_ the "usual" place where files like that go, ~/Library is a hidden directory. I feel not a lot of people who are new to programming (like manim often attracts) would feel comfortable poking around in hidden folders. It's not _dangerous_ or anything, it's just kinda wierd.

I don't have a very strong opinion on this, in fact I actually prefer the current location, so I'm curious to see what you all think.

It is worth noting that many packages and programs I've come across (including, for example, vim and zsh modifications) use a ~/.config/<name>/ folder for their config files. We could follow this pattern

I think the already suggested is implemented. @PgBiel

I think the already suggested is implemented. @PgBiel

@naveen521kk Not on MacOS

Was this page helpful?
0 / 5 - 0 ratings