-
Notifications
You must be signed in to change notification settings - Fork 11
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
Support for dependency exclusion ? #80
Comments
I am not sure I am completely following what you want to do. Is the following a good summary? In the toolbox registry there is a .json file A.json, which itself includes several other toolboxes, as in includes that reference B.json, C.json and D.json. Now you have a project, and A.json has almost exactly what you want for that project, but you don't want to have C included? So in other words, you want to write a project dependency file that says, use A.json but have some syntax that let's you remove from C.json from what A.json does? That would then allow you to explicitly include some other more extended version of C (e.g., C-extended), as part of your test project. Assuming I've got the idea, there isn't currently a way to do this. I have dealt with this issue by avoiding that level of indirection. So, for example, there is a BrainardLabBase.json file in the registry, that includes a bunch of repos that constitute a fairly standard setup for stuff many people need in my lab. But, sometimes I only want a subset of what's in there. In that case, I just write out my project .json explicitly. This doesn't seem obviously worse than how I could do it if I included BrainardLabBase in the proejct .json and then explicitly excluded some things. I guess it could be worse if BrainardLabBase.json were a very long file, or if I expected my project would want to inherit future changes to what was in BrainardLabBase. The easiest way to implement this might be to add a field (say, "subexclude") that had a list of names. This would cause TbTb to ignore any entries in an included .json file that matched names in the list. This would only be easy, I think, if the "subexclude" action were limited to looking one level down. That is, if A subexcluded B, but A included C which included B, then you'd still get B. That kind of thing is one reason not to go down this road unless it seems really important. Let me know your thoughts. |
Thanks for the quick response. Yeah, This is what exactly I was asking and if you are in favor of implementing "subexclude" with one level down. I can try it. |
Sure, if this would be helpful to you go for it, and then issue a PR. I would do the check on the "name" field of the included toolboxes -- that seems like an easy place to stick in an unambiguous check. Depending on how TbTb implements the includes, this may be very easy. |
How about having support for dependency exclusion?
For example, there exists a Toolbox -A which has {B. C, D} in "include" dependency. When I want to use tool box - A as a dependency in the project "Test Project", is it possible to exclude C and configure another repo say "C-Extended" in my Test project.
Reference: https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
The text was updated successfully, but these errors were encountered: