An argument was made in a GitHub issue [1] that the decentralized model for packages where each package is a distinct git repo may be inconvenient for some use-cases and that allowing multiple packages to reside in single git repo would be better.
I think supporting that would significantly change the design and goals of the package manager, so I wonder what ideas/thoughts others have about the current model vs. the proposed one?
- Jon
I don't think we should change the design of the package manager based on that use case. I think that the user is currently experiencing a moment in time where virtually no packages exist yet and assuming that no packages will exist in the future based on that fact. All of the packages that the user placed into their big script repository are scripts that hopefully will eventually be turned into packages and more easily installed.
The user could still package all of their scripts into a single repository and have a script mechanism for choosing which scripts to actually load on different systems (i.e. @if directives choosing to load certain scripts on different systems, etc).
.Seth
I concur. While I can see the point that was brought up, I don't think
it will be much of an issue for most users. I think we even discussed
this alternative structure early on during the design phase. The
assumption of one package per repository simplifies the package
manager significantly, which to me justifies the trade-off here. I
could see reconsidering this as we gain more experience with use cases
and generally how people end up using the package manager, but for now
I don't see a need change anything. I doubt that the current model is
what would prevent people from creating packages.
Robin