godot: Don't store the .import file when using the default settings
Godot version:
master @ 99640ac583f560771d0ceab3cde7e567f5cdff47
I know this has been dismissed before but I didn’t find a proper issue about the topic, so I’m reviving the points about it. This is the result of a discussion I had with @jahd2602.
The problems
- The
.importfiles sitting besides the assets clutter the folders. Essentially we have double the amount of files in the project, making it harder to manage. - While those files are small, there are many of them and they occupy space in the repository. They also need to be dealt with when doing merges.
- Deleting, renaming, and moving assets require doing the same process to the related
.importfile. Failing to do so make the.importlive there on its own, since there’s no cleanup tool. While doing those operations with the FileSystem dock makes the.importfile go with it, it’s not always feasible to use the Godot editor for this. - Changing the default import settings to apply to all resources requires you to delete all the
.importfiles related to them. - They occupy space in the exported project, even though the import options are not relevant there anymore.
The solution
Don’t store the .import file when the resource is imported with default settings.
The problems with the solution
- We still need the remap information, such as path and type. This can be solved in the editor by asking the importer, but it’s still needed on export. And while this information can be generated at export time, it breaks the possibility of running the source project with the release template.
- If the user change the default preset settings it should re-import everything (of the same type), but it’s not clear for the editor to know what should be re-imported.
- If the new default is the same as an existing
.import, it’s not clear whether it should be removed. - If we want the settings of a particular resource to be same as the default but not change with new defaults, it’s not simple to force a
.importfile (though there could be UI for this).
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 25
- Comments: 21 (17 by maintainers)
BTW I did a proof of concept of this proposal. Still don’t solve all the issues. I save the
*.importfiles inside the.import/folder when they have default settings, so they are still there for the remap check but doesn’t need to be tracked.Link to my changes: https://github.com/jahd2602/godot/compare/3882e0d006efbd076bdc6d08fb844e006d30e718...98eb965deda3cfcf2fbd509ca170aa0c36f
A note about the space .import takes, I think it has been reported that files in it are not always cleaned up, so it often grows unnecessarily over time (though I can’t seem to find an issue about it?). This in particular should be an improvement to work on as far as space is concerned, but otherwise I agree with @NathanWarden.
About .import files cluttering the project… I just don’t bother anymore. I’m used to it (and all points listed), working with Unity half of my time in a team project, there are such files even for scripts. We know what they are for, they aren’t complicated (even readable) and in the end clutter is relative, because we don’t work often directly with the raw filesystem for convenience and perhaps even scalability (editor’s asset browser, IDE script explorer etc). In that sense I would kinda not like the fact
.importfiles sometimes are there, sometimes aren’t, based on some exceptional rules about default properties, because it makes their behavior a bit more complicated. But overall I’m just used to that. I guess the benefit comes if you never change import settings?How come they end up in exported projects though? I thought they were mostly useful for project edition cycle?
@girng @Zireael07 In that case: https://github.com/godotengine/godot/issues/23368
I’m fine with not saving default import flags, but only if users are asked to select import presets for their resources when they create a new project, and this setting is saved (in
project.godot). This way they know that their import flags won’t magically change when upgrading their Godot version, as we’ll treat any change to preset defaults as a compatibility breakage.They contain the path remap information, so the the engine knows that the PNG you’re referring to is now a STEX in the
.importfolder. They also still contains the import parameter, which I think should be stripped on export, but that’s another topic.That’s one of the problems. IMO though, if you are importing everything with default is because you want the defaults, even if they change.
This can be done. Right now the changed defaults are stored in
project.godot.I want to add that a major point is that it’s not always immediately clear what the
.importfiles are for. This discussion started because of a project I joined and they were ignoring all the.importfiles in.gitignorebecause they were generated automatically, so the files don’t seem important to the repository.The current behavior is not as intuitive as one might think.
I don’t think there’s much of a difference since it creates the files with defaults without asking anything already. The difference is just not creating the files with the defaults. Also this all can be improved, and maybe they should anyway regardless of this proposal (same goes for the current defaults).
This is not a big deal because it’s only on the working directory. The imported assets can be ignored in the repository and the originals don’t go to the exported version. In fact, this proposal does not get rid of the duplication, which is necessary to make Godot recognize the files (many resource types can change a lot in size after imported).