I’ve found a use-case where our team would like to split the package manager manifest into two separate files: 1) The default manifest with builtin modules and project packages. This file would be committed to version control as usual.
2) A separate user manifest package file where individual users (local machine) can add their own tools without comitting them to version control.
We would like to use such a workflow because there are a couple of tools which are only used by a single developer on the team and because there are a couple of tools with which we would run into legal troubles if we were to add them to the repository. Basically, a private user manifest file would allow us to use tools that should never leave our network, while still maintaining the benefit of an easy setup.
Would Unity consider such a feature or does anyone have ideas how to pull this off cleanly? Also, is there anyone who thinks this would be a desirable feature at all or should we approach our issues from a different angle?
There is a feature that we want to introduce that could fulfill part of your idea. It is the concept of developer dependencies (similar to NPM’s devDependencies). That is, dependencies added to the project only if it is in development mode. How this mode is set is TBD. But, a good option would be to set this mode if the package is mutable (local or embedded packages). I think it would be a good start (potentially resolved the legal issue?) but it only covers part of your suggestion though.
The other part would be to support a per-user package override. This one is a bit harder to rationalized when considering one of the core values of the Package Manager: determinism :). This would make a project behave differently on various computers. Are you ok with this?
I guess in my very specific use case it would be helpful, but I see the point with determinism. Unity philosophy is usually that everything works out of the box, anyway, so this might contradict complex local dependency setups. Not sure what the best solution is, but just raising my concern that my company has packages as part of a project that shouldn’t leave our network while the main project is hosted elsewhere.
I understand. This is a rare but interesting use case :P. Could you set up an automated CI flow stripping the package reference before making the project distro to be hosted elsewhere? The script can be relatively trivial to write. Not sure how you are set up but that would be my first instinct if I had this requirement on my project.
I just remembered about another feature that was discussed in the past but I’m still not sure if we should implement: “User or computer level scoped registry configuration”. This could also be used to fix your issue. But, again, this feature is also debated internally because it would break the determinism core value
