Don't forbid unknown files in a library

[mfalkvidd]

Warning about unknown folders was considered bad in
arduino/Arduino#1692
but the problem is still present in arduino-builder.

This has caused issues like
#70 (comment)
which resulted in
#162

The original arguments in Arduino/pull/1692 still apply:

• It breaks forward compatibility if we later add more files or
  directories to the library format.
• It breaks for people who want to have some extra stuff in their
  library. We can't keep a list of "allowed" stuff, since there will always
  be stuff missing.

Signed-off-by: Mikael Falkvidd [email protected] [email protected]

[facchinm]

Hi @mfalkvidd , the warning was reintroduced one commit later (arduino/Arduino@3bec912) and it's quite useful to enforce libraries uniformity. The hidden VCS folders will evolve over time, but since it's a warning there will be no functional problem in compiling a new library with an old arduino-builder

[fallberg]

Sorry, but this warning is just stupid. Why do you show a warning for something that had nothing to do with your IDE? Why can't people use well defined standard directory structures for organizing things just because Arduino IDE references files in the tree? All this warning does is giving concern and worry to inexperienced users.

[tbowmo]

So we should just tell users, "Yes, you see a warning, but it's nothing".. Which is just plain wrong..

imho all warnings should be dealt with.. And we could just as well start by educating this to users.

Now this warning will make it impossible to make a build / linter tools directory and distribute via the repositories. This shouldn't be visible to normal users, as they shouldn't need to change anything in this directory, but still be available to advanced developers.

[bblacey]

@facchinm, there has to be a better solution.

It is often considered best practice to name supporting files as 'dot' files so they are hidden during normal directory traversal yet available to tools within the repo namespace for things like Travis-CI that names its config file .travis.yml. Furthermore, users often place their continuous-integration files in folders that begin with a dot such as .travis; the same goes for other hosted CI services like Circle-CI and the list goes on including this recent example

Bottom-line: The approach used for the Arduino IDE is dated relative to the broader perspective of how to develop manage and test a product within a git repo that transcends multiple-tool usage. Said another way, the IDE is fully within it's right to complain about unknown files within a sketch directory that is defined by the IDE but the IDE is just a single tool amongst many that is used within the scope of a repo and should not interfere with usage of other tools within the same namespace as it is currently doing.

Currently, the IDE attempts some tolerance by ignoring well-known dot directories such as .git, .svn, etc. but this is hardwired into the source code (not extensible by users)...

One potential solution would be to use the well-established convention (many, many tools use this convention) of implementing an .arduinoconfig to provide the IDE with namespace-specific configuration settings. This would be a convenient place to provide IDE configurations for a given namespace with one configuration setting being a list of items within the namespace to ignore.

[matthijskooijman]

@facchinm, I'd also consider reopening this issue and removing the warning, since it doesn't seem to add much. What are we trying to keep out of libraries? Object files? Should we perhaps add specific warnings instead?

[facchinm]

I believe the warning is there only as a (gentle) reminder for library developers; someone could say it is wrong to ship a library the stray useless files in it (and versioning folders are useless from a user's POW).
For example, if you download (not clone) a library from github it loses all the versioning info. This is also the standard behaviour of every FOSS library available.
Following this philosophy, whitelisting dot-folders is wrong, since these warnings should be reported anyway if the developer activates a flag, while they should be invisible by default.

Could adding a particular tag to the warning and filtering it in IDE UI be a good solution for everyone?

[fallberg]

@facchinm well you can definitely not make the judgment from Arduino IDE if files and folders in a library repository is useless or not. It could well be used in other non Arduino contexts where the files and folders are very much in use. So at the very least, there should be a possibility for a library to whitelist its own files.

[PaulStoffregen]

When/if you add new features to the library spec (at least ones involving new folders & files), this will slow their adoption because library authors usually wish to support at least the last couple years of IDE releases which many people still have installed. Maybe that's ok?