On 2015-12-02 15:12, Erik Dalén wrote:
A related ticket to the interface and redirect functionality is
https://tickets.puppetlabs.com/browse/FORGE-111
There I just suggest the feature to be able to say that module B
provides the interface of module A version X. So either module can
satisfy a dependency on module A version X.
Then if you want to have some sort of generic interface that other
modules can implement, you could have a sort of virtual module with he
version being the interface version. And then other modules provide or
depend on that virtual module. The meaning of virtual module here is the
same as for virtual packages in package managers, like
"ruby-interpreter" or "smtp-server" in Debian, and the implementation
would also be pretty similar.
Regarding having multiple variants or versions of a module being
installed at the same time I think we should change the environment
loader API to provide a list of modules instead of a list of module
paths. Then plugins could implement any sort of behaviour for this
without jumping through hoops.
I have claimed on many occasions that an environment is just like a
module (with higher privileges / precedence). The set of available
modules should be more of a repository kind of thing that the loader
resolves modules from.
Essentially this is how the new loaders work (used only for 4x functions
so far).
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/mbii8r%24mae%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
