Godot: The .import folder should be renamed

Created on 29 Oct 2018  路  19Comments  路  Source: godotengine/godot

Godot version: 3.0.x and master, any recent version

Issue description: Currently, it can be confusing that there is both a .import folder in the project root, and .import files located next to the actual source files in the project. When people refer to "the import files" it's not immediately obvious what they're talking about. It seems that even the Godot devs got them mixed up in the official demo projects repo and gitignore'd important files.

These files are quite different and the names should be different to reflect this. In my opinion, the .import folder should be renamed to .cache because it contains cache-like imported files. The files in this folder can be safely deleted and regenerated, and they persist after an editor restart (so they're not "temp" files). This is the behavior that most people would expect a "cache" to have.

Actually, it would be much better to have a .godot folder and put all ignorable stuff inside that, so .import would be renamed to .godot/import or .godot/cache or similar. EDIT: See #38607

archived enhancement editor

Most helpful comment

Going with .godot is the best option IMO. It's pretty common convention, e.g.: .vscode, .idea, .vs, .github, etc. Although it may not be obvious whether all the contents should be ignored, as in some of those examples there are files that you may not want to ignore.
Having a single folder simplifies ignoring files and it also opens for the possibility of storing some editor related information inside the project. See cases like godotengine/godot-proposals#555 (right now Rider has to find the editor settings location on all systems).
It also means a single root directory for a .gdignore file. Adding .gdignore file to .mono (there's already .import/.gdignore) is a pending task, and it wouldn't be needed if it were located in .godot.

All 19 comments

Some discussion ongoing in the PR, but there was a recent comment on another issue that showcases possible confusion stemming from similar names: https://github.com/godotengine/godot/issues/24177#issuecomment-445420397

I said in the PR but to add it here too: I find .cache a bad name because it doesn't convey what the folder is for. "Cache" means storing a result for faster access later and the process can be redone if the cache is not there. While the .import folder can be recreated by the editor, it's needed to run the game, and you can't generate that folder in-game.

:thinking: Perhaps something like .generated would be suitable then.

Why not .resourceinfo? Or .assetinfo.

Well, it's not really information, it's for generated files after Godot has imported them.

.imported would be another name that is different, but still similar to .import. It could still be ambiguous, but at least it would be somewhat different.

It contains information on how to handle resources. I know why that would be technically incorrect, but it's much clearer, at least to me. Maybe .importinfo

If anything I would expect the .import files next to assets to be .importinfo since it literally stores user editable resource import information. So no, .importinfo is not suitable.

I would rename the files to .import_info and the folder to .imported_assets so it's clearer what they do, even if the name is a bit long.

What about _.necessities_ since they necessary to run the game?
And/Or rename the files to _.import_link_.

Well we could name it .important with the same success :smiley:.
The problem with .necessities/ is that it would confuse people into including it in VCS, which is precisely what they should not do. (Assuming that it is about the folder; if it is about the files, "necessities" is too close a word to "dependencies", so it wouldn't work there either.)

I still think that the best candidates so far are .cache or .generated. While it's not technically cache, .cache still conveys to the user what they need to know, which is that it should be gitignored. I really doubt that somebody will try to delete a folder called .cache before running the game. .generated is more accurate and still reflects that it should be gitignored and not deleted.

EDIT: .godot/imported is better.

If length isn't an issue, how about .engine_generated_cache or .editor_generated_cache

Another possible solution is to make "import" (or similar) a subfolder of a more generic .godot folder, as @vnen suggested in this comment: https://github.com/godotengine/godot/issues/20994#issuecomment-413091756. We could also put .mono in here.

.godot/imported_cache? </bikeshed>

Just to add: There is a nice correlation between the .import folder and the Import tab.

Going with .godot is the best option IMO. It's pretty common convention, e.g.: .vscode, .idea, .vs, .github, etc. Although it may not be obvious whether all the contents should be ignored, as in some of those examples there are files that you may not want to ignore.
Having a single folder simplifies ignoring files and it also opens for the possibility of storing some editor related information inside the project. See cases like godotengine/godot-proposals#555 (right now Rider has to find the editor settings location on all systems).
It also means a single root directory for a .gdignore file. Adding .gdignore file to .mono (there's already .import/.gdignore) is a pending task, and it wouldn't be needed if it were located in .godot.

I was mistaken. It's not res://.import that has a .gdignore file. It's res://android/build.

Why not just .runtime or .runtime_resources? At the end of the day that's what the .import folder contains and those are the resources used at runtime. The .mono folder can go into that too I guess.

I'd also add a .project folder that would contain all the project metadata needed.

The only problem with .godot is that people will think it contains specific editor configuration for that project not what it really contains (resources used at runtime)

Closing in favor of https://github.com/godotengine/godot-proposals/issues/1521, as feature proposals are now tracked in the Godot proposals repository.

Was this page helpful?
0 / 5 - 0 ratings