feat: allow bundle to take multiple inputs to take advantage of bash's wildcard

[luanpotter]

Status

READY FOR REVIEW

Description

Right now, if you provide more than one file for mason bundle, it will only look at the first file. That is because the implementation is only considering the .first element of the rest array, instead of all.

That means that you can't leverage the wildcard operator in bash; for example:

mason bundle bricks/* -t dart -o lib/templates/bricks/

Will only generate the first bundle:

That makes it hard to automate build scripts, as it would require an actual bash script for loop to bundle all files.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[felangel]

@luanpotter I took a closer look at the changes and I'm a bit uncertain about merging these changes because the approach doesn't appear to work well in cases where you want to bundle multiple bricks from different sources. For example, how would you be able to bundle multiple bricks from git urls? I'd love to align on an API that supports bundling from multiple sources (e.g. bundling multiple bricks from git, path, and registry sources). Let me know what you think and thanks again for the PR 👍

[luanpotter]

hi @felangel, thanks for the response. it does allows for multiple bricks of any source, but only one source at a time. So you can bundle multiple bricks from git url, as long as they are all git.
I thought that was fine because if you do want to bundle from multiple sources you can call the command up to 3 times, since the # of sources is very low cardinality. it is more problematic if you want to bundle say 100s of bricks, but with this you will always be able to group into at most 3 commands (or less). also the main advantage I was seeking was to be able to leverage bash's wildcard operator, that only works for files, so I didn't even consider this being used for other sources.
that being said, I can definitely change to support multiple different sources on the same command, but not sure how that API would look like, do you have any preference?
happy to change this to follow whichever syntax you think fits best :)

[felangel]

hi @felangel, thanks for the response. it does allows for multiple bricks of any source, but only one source at a time. So you can bundle multiple bricks from git url, as long as they are all git. I thought that was fine because if you do want to bundle from multiple sources you can call the command up to 3 times, since the # of sources is very low cardinality. it is more problematic if you want to bundle say 100s of bricks, but with this you will always be able to group into at most 3 commands (or less). also the main advantage I was seeking was to be able to leverage bash's wildcard operator, that only works for files, so I didn't even consider this being used for other sources. that being said, I can definitely change to support multiple different sources on the same command, but not sure how that API would look like, do you have any preference? happy to change this to follow whichever syntax you think fits best :)

Thanks for the quick response! How would the current API work with bundling multiple bricks from git?

[luanpotter]

Sorry for the delay, had a busy end of the week!
Multiple input should work for all input types just the same:

mason bundle --source git url1 url2 ...

if you want, I can add a test case specifically for this case.

however, after looking deeper on how the "git" source works, I think I know what you might have been talking about -- you will need to provide the same git-path for all sources.
is that something that you think should be specified per brick?
or were you thinking of something else?

[felangel]

Sorry for the delay, had a busy end of the week! Multiple input should work for all input types just the same:

mason bundle --source git url1 url2 ...

if you want, I can add a test case specifically for this case.

however, after looking deeper on how the "git" source works, I think I know what you might have been talking about -- you will need to provide the same git-path for all sources. is that something that you think should be specified per brick? or were you thinking of something else?

The case I was thinking of is adding multiple git sources from different git-url, git-path, and git-refs. Ideally if we support multiple sources we should truly support any combination of multiple sources and not restrict it to just multiple sources from the same git-path and git-ref. Let me know what you think and thanks again!

[luanpotter]

What would you think of incorporating all that information into the url?
So something like [https://github.com/felangel]/mason/blob/[master]/[bricks/bio/brick.yaml]
Instead of having to separate that into repo, ref and path
Otherwise not sure how this syntax could look like