-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mini-tools collections #167
Comments
@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. |
@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: |
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 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. Of course, |
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 keycollection
list variuous path as keys and sub-data as valueIn that case, suppose to use it in this way:
In this case who goes under the bpkg name (skip to add orgname in the package)
Benefits
Links
@jwerle @Potherca @samlikins does that make sense for us?
The text was updated successfully, but these errors were encountered: