Should we add files for other IDEs as well? Or none at all?

Should we add files for other IDEs as well? Or none at all?

I was going to ask the question. It seems to me, if one is worthwhile adding then we may as well add the others.

In the .gitignore of the actual repo there is also:

# Pycharm
.idea/
# Notepad++ files
nppBackup/

...in terms of IDEs/editors.

Btw, I usually add these to ~/.config/git/ignore so that it is global.

Not sure what you want to do with this, but if it's not deemed worthwhile feel free to close. Otherwise, happy to make any changes you'd like...

Not sure what you want to do with this, but if it's not deemed worthwhile feel free to close. Otherwise, happy to make any changes you'd like...

My personal policy is to not add those and let users deal with a local non-versioned .gitignore or their own global config. However, a conda-forge feedstock is not your common code base repository, and many users with multiple backgrounds (workflow, editors, etc) are welcomed to contribute. So, adding these to the default gitignore is a good idea IMO.

What do you think @isuruf?

My personal policy is to not add those and let users deal with a local non-versioned .gitignore or their own global config.

Same here

However, a conda-forge feedstock is not your common code base repository, and many users with multiple backgrounds (workflow, editors, etc) are welcomed to contribute.

Exactly. So, it's better to ask users to add these to their global config IMO.

I'm a reasonably experienced developer and I didn't have a global git ignore configured so I think you can expect most people don't and in particular, inexperienced developers won't. The default experience they'll have is their editor creating folders which aren't ignored and which their editor will want to automatically commit unless they're careful to unselect the config folder.

It's just one more barrier to entry which the core devs don't experience because they already know what a .gitignore file is, how config file hierarchy's work and where to find the global config file on their system.

I think letting users deal with their own global config is pretty hostile to inexperienced devs/analysts when there's literally zero cost to making it Just Work for them out of the box AFAICS.

Exactly. So, it's better to ask users to add these to their global config IMO.

@isuruf the thing is, we don't want to ask/teach that many people on how to set their global configs! That is why, even though this is not my usual workflow, I think it is a good idea here.

My point is that either we should add none, or add a reasonably comprehensive list. Anything in between is worthless.

I think letting users deal with their own global config is pretty hostile to inexperienced devs/analysts when there's literally zero cost to making it Just Work for them out of the box AFAICS.

And your statement isn't hostile?

How about just adding just the files needed as in, https://stackoverflow.com/a/987162/4768820 ?

And your statement isn't hostile?

Sorry, that wasn't intended to be hostile towards you so I apologise for the tone of that statement.

I work with a lot of inexperienced devs, particularly without much git experience so I'm just interested in making the workflow as easy as possible for them.

My point is that either we should add none, or add a reasonably comprehensive list.

I think that's a fair point. For Python you could use the GitHub template:
https://github.com/github/gitignore/blob/master/Python.gitignore

...but then not every feedstock is a Python repo. My thought was that IDE/editor ignores will be common for all feedstocks. If there are other generally applicable ignores we should add I'm happy to do so, I'm just not sure what they are.

How about just adding just the files needed as in, https://stackoverflow.com/a/987162/4768820 ?

What do you think about this? Instead of rejecting IDE files in .gitignore, just approve files that we want?

I think it would be pretty tricky to whitelist files in a .gitignore.

Maybe it could be made to work if it was just the top-level folder which should be (entirely?) auto-generated. If someone did try to add a non-whitelisted file it might be pretty confusing for them though.

I wouldn't be confident making that change as I don't think I've got a broad-enough view of all CF development to know what files should be whitelisted.

If this doesn't add enough value I'm fine with it being closed. For me, conda-forge/staged-recipes@90e5e59 was the more important change. Since the feedstock .gitignore will necessarily be incomplete perhaps this change isn't worthwhile.

I wouldn't be confident making that change as I don't think I've got a broad-enough view of all CF development to know what files should be whitelisted.

I was thinking of just

*
!recipe
!.ci_support

Auto-generated files are added by conda-smithy forcefully anyway. If a user changes the templates, then they'll be shown by git because they are already added to git.

I can make that change if people think that's better (or feel free to push yourself).

I'll leave this open for a bit to let others comment - there's no big rush...

This is an interesting approach. Though IIUC we will need to stay vigilant when adding new files to feedstocks that they are properly handled in .gitignore (it appears there is some indirection here as well that we need be aware of). Does the test here make sure new files added do show up in feedstocks as well?

Does the test here make sure new files added do show up in feedstocks as well?

I don't understand the question. Can you clarify?

Ping on this

My personal policy is to not add those and let users deal with a local non-versioned .gitignore or their own global config.

Note that the changes here (specifically !/recipe/**) actively breaks the ability of global ignore config to ignore any subdirectories (e.g. nppBackup) under /recipe. This resulted in committing junk files across multiple feedstocks, some permanently committed to main that I'll have to make another PR to clean up, and ended up costing nearly two hours of maintainer time to fully debug and document.

I've opened #2327 to document and track this.