I would like to propose support for declaring a subfolder within a remote Git dependency using a ?path= URL parameter.
For example:
https://github.com/user/proj.git?path=/libraryA
This would allow a repository containing multiple Beef projects or libraries to expose individual subfolders as separate dependencies.
The syntax is based on how Unity’s package manager handles Git dependencies that live in subfolders. While ?path= is not part of standard Git behavior, it is a familiar pattern for this kind of package-manager-level feature.
I have started prototyping this locally and will likely be submitting a PR for it, but it was mentioned that i should also open an issue for it.
Some repositories are structured as monorepos, or otherwise contain multiple related Beef projects. In those cases, it would be useful to depend on a specific project folder within a Git repository instead of assuming the dependency root is always the repository root.
For example, a repository might look like this:
BeefManaged.toml
libraryA/
libraryB/
shared/
Setup/
A consuming project could then reference one or more projects from that repository:
https://github.com/user/proj.git?path=/libraryA
https://github.com/user/proj.git?path=/libraryB
To me ideally If both dependencies resolve to the same repository and revision, they should reuse the same clone in the managed libs folder.
This avoids cloning the same repository multiple times just because different dependency declarations reference different sub-folders.
This would keep the folder naming inside the managed libs folder the same as previous versions. (The key being the commit hash)
Along with this approach it will require a updated file version for the BeefManaged.toml format:
FileVersion = 2
Version = "v1.0.0"
GitURL = "https://host/repo.git"
GitTag = "v1.0.0"
GitHash = "abc123"
[[Projects]]
Path = "."
Setup = true
[[Projects]]
Path = "libraryA"
Setup = true
[[Projects]]
Path = "libraryB"
Setup = false
One thing we need to determine with this single repo multi-project behavior is how we want to handle to Setup folder logic. Do we want to have a Setup/ per project. or should it only be per repo.
Currently i've got the above example doing it per project since this has a smaller blast radius in the code generally, but i also think per-repo could make a lot of sense if we would change it to pass in a argument to the setup that passes in the path to the project being initialized. And this would reduce the amount of repo noise for having duplicate setup projects throughout the repo.
But if we want to opt for a much simpler scheme we could change the managed libs folder to have a different folder name(commit hash + path or something) and keep to only 1 project per libs folder. I don't think this is the best approach though.
I would like to propose support for declaring a subfolder within a remote Git dependency using a ?path= URL parameter.
For example:
https://github.com/user/proj.git?path=/libraryAThis would allow a repository containing multiple Beef projects or libraries to expose individual subfolders as separate dependencies.
The syntax is based on how Unity’s package manager handles Git dependencies that live in subfolders. While ?path= is not part of standard Git behavior, it is a familiar pattern for this kind of package-manager-level feature.
I have started prototyping this locally and will likely be submitting a PR for it, but it was mentioned that i should also open an issue for it.
Some repositories are structured as monorepos, or otherwise contain multiple related Beef projects. In those cases, it would be useful to depend on a specific project folder within a Git repository instead of assuming the dependency root is always the repository root.
For example, a repository might look like this:
A consuming project could then reference one or more projects from that repository:
https://github.com/user/proj.git?path=/libraryAhttps://github.com/user/proj.git?path=/libraryBTo me ideally If both dependencies resolve to the same repository and revision, they should reuse the same clone in the managed libs folder.
This avoids cloning the same repository multiple times just because different dependency declarations reference different sub-folders.
This would keep the folder naming inside the managed libs folder the same as previous versions. (The key being the commit hash)
Along with this approach it will require a updated file version for the
BeefManaged.tomlformat:One thing we need to determine with this single repo multi-project behavior is how we want to handle to Setup folder logic. Do we want to have a Setup/ per project. or should it only be per repo.
Currently i've got the above example doing it per project since this has a smaller blast radius in the code generally, but i also think per-repo could make a lot of sense if we would change it to pass in a argument to the setup that passes in the path to the project being initialized. And this would reduce the amount of repo noise for having duplicate setup projects throughout the repo.
But if we want to opt for a much simpler scheme we could change the managed libs folder to have a different folder name(commit hash + path or something) and keep to only 1 project per libs folder. I don't think this is the best approach though.