Mini-tools collections

[francescobianco]

I'm here to discuss a relative common scenarios I have found.

Many people host in the same repo (links below) multiple tools (micro-tools), I thinks, to avoid to have a large amount of repetions of the same git repo into the various phases of publish a new package on the registry.

Having something to act as package collector for multi-tools repo is in my mind, but not clearly how land on this.

Just for hypothesis

A file in the root of the project called bpkg.json with a special key collection list variuous path as keys and sub-data as value

{
  "collection": {
     "xcat2": {
             "name": "xcat2",
             "path": "bin/xcat2",
            "license": "..."
     },
     "special-split": {
             "name": "special-split",
            "path": "bin/special-split"
            "license": "..."
     }
  }
}

In that case, suppose to use it in this way:

bpkg install orgname/reponame/[email protected] -g

In this case who goes under the bpkg name (skip to add orgname in the package)

Benefits

• Tool-maintaner can host all of your code in one place avoid fragmentation. Instead tool user, can install the only needs and not the entiere list of tools
• Single micro-tool can have independent page on the registry separated to the collection page, in this case focus on tool is good instead of focus to install a non-homogeneous repo of micro-tools

Links

• https://github.com/oldratlee/useful-scripts/tree/dev-2.x/bin
• https://github.com/mertcangokgoz/UsefulBashScripts/tree/master/Scripts

---

@jwerle @Potherca @samlikins does that make sense for us?

[samlikins]

@francescobianco: I personally would vote against that idea. A repository is a single set of files for a specific use case. Using the dependency structure, a set of required projects could be included, but not the reverse. Trying to force multiple tools into a single repository may sound like a nice way to "simplify" things, but it makes it much more difficult in many other ways, not to mention the complexity it introduces in the package manager aspects.

[francescobianco]

@samlikins Thank you for sharing your perspective! You've raised an excellent point that I hadn't considered before. There is indeed a significant risk of leading developers towards bad practices.

My initial idea was inspired by the trend of using repositories as a collector for individual libraries, similar to what happens in the Cargo ecosystem or in the JavaScript world, where multiple packages reside within a single repository, often organized under directories like 'crates/' or 'packages.'

Your insight highlights the importance of carefully evaluating the potential drawbacks of such an approach. I appreciate your input, and it will definitely help us make a more informed decision moving forward.

Some links:

• https://github.com/MarcoIeni/release-plz/tree/main/crates
• https://github.com/vercel/turbo/tree/main/crates
• https://github.com/vercel/turbo/tree/main/packages

[Potherca]

Personally, I have a great dislike for the mini- and micro-package paradigm.

I do have individual packages that offer (multiple) sub-functions but instead of adding those as dependencies for the end-user, I copy their content into the repo. (A bit like committing node_modules only with a couple of thousand files less...). Not the files themselves, mind you, only the bits that I use (see inline-source below).

Depending on how the original script is written, this gives me the choice of exposing sub-function to global scope, or not. This also helps avoid version collision between different script depending on different versions of vendor code.

My projects generally have a main script file which includes (i.e. source) files from my code src or dependencies (in deps). I then use potherca-bash/inline-source to create a distribution file that has all the code in a single script.

Of course, inline-source itself is also build in this manner (see the repo for details):