Having a flag to prevent .gitignore files from being created about spin HOT 9 CLOSED

Fixed via #2370 - thank you @thesuhas

from spin.

I marked this as a good first issue, before realizing it might have a few implications for the template system.

@itowlson -- what do you think about this one?

from spin.

@radu-matei YOLO

Er

Yeah I think that's okay. It has I think two or three touch points, but there is already technology in there for skipping files, so hopefully nothing too onerous.

from spin.

@thesuhas — would you be interested in contributing this feature?

from spin.

@radu-matei I would! Although I have no idea where to get started. It would be great if you could point me in the right direction

from spin.

@thesuhas Thanks for stepping up! Regarding pointing you in the right direction: here are the things I'd be thinking about and the areas of the code I'd be looking at:

1. Decide if this is a per-template prompt or a built-in command-line option. We can discuss that on this issue.
   a. If it's a built-in command-line option, you would add it in src/commands/new.rs and pass it through in the spin_template::RunOptions (https://github.com/fermyon/spin/blob/main/src/commands/new.rs#L176).
   b. If it's a template prompt then we need the template engine to understand parameter semantics, which is a new concept but way more flexible in the long run.

2. Determine how to identify which files to exclude. This might need some design (and might depend on the outcome of option 1). Alternative ideas:
   a. Have the template engine understand .gitignore as a special file that is conditionally excluded.
   b. Use a naming convention for files that may be conditionally excluded.
   c. List files to be conditionally excluded in the template metadata.

3. Implement conditionally excluding a file (or set of files). The set of files to copy is determined in crates/templates/src/template.rs, in the Template::included_files() files function. This is currently fairly static, so either you need to modify it to accept dynamic decisions, or you need to post-process it in Run::included_files() (in run.rs) - either way, you should have all the info you need at the call site.
   a. My inclination here is to do the evaluation inside Template::included_files() and avoid complicating Run::included_files() (which is more interested in taking snapshots of the files already deemed included). This opens up some nice abstraction opportunities where only the Template needs to care about how abstract options like "no VCS" map to concrete files in its own particular case.

To be clear, I say this not to tell you what to do, but to support you figuring out how you want to approach this! I hope it doesn't come across as micro-managing. Please feel free to ping me if you want to discuss further or need more pointers - I'm very happy to help and support you.

from spin.

Hi,
Sorry for the extremely long delay.
I've added the option as an optional command line flag in TemplateNewCommandCore. I am using this flag in RunOptions in crates/templates/src/run.rs. This is being accessed in included_files and I am conditionally filtering out the all_content_files based on the value of this flag.
I've tested it locally and it works but the tests are failing. This is due to a build issue in crates/templates/src/manager.rs where RunOptions is being initialised in multiple tests.
I was just wondering if it could be provided as false for all of these tests and if that would be fine?
Additionally, would it be okay if I added a test case in crates/templates/src/test_built_ins/mod.rs to verify that the .gitignore file is being conditionally created or not?

from spin.

Yes, setting the new flag to false in existing tests is fine.

For testing the flag, it would be preferable to do it in the manager tests, which have come to include the run behaviour tests. But if that turns out to be painful then test_built_ins would be okay.

Thanks for the update and for staying with this!

from spin.

Hi,
I opened a pull request: #2370

from spin.