I'll resurrect this old thread to give an update. We landed a function
in stdlib to do some of what I discussed in my last post, by inspecting
module metadata directly.
The function:
https://github.com/puppetlabs/puppetlabs-stdlib#load_module_metadata
A blog post I wrote about some possible uses:
The use case I think for having multiple modules of the same name
available is quite limited. I don't think anyone would claim best
practice if they had two apache modules in their modulepath.
I also think there is another component which is versioning. Right now
there is no system for a profile
On 2015-20-02 20:51, Wil Cooley wrote:
In some ways, this is a lot like environments, but unlike environments,
which are unique at the node-level, these allow the use of multiple
module-sets and are scoping for entities at the manifest-level. As I
understand environments, they can (and probably
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
On 2015-10-02 1:23, Trevor Vaughan wrote:
I was talking with a few folks today about potential resolutions to
module namespace issues.
== Fundamental Issue ==
puppetlabs_apache -- Installs To -- apache
example42_apache -- Installs To -- apache
theforeman_apache -- Installs To -- apache
You
I'm personally more of a fan of what some programming languages call
interfaces; a sort of contract if you will that a module implements.
So for instance olindata::galera could look for any class that implements
the IMysql interface. That way, I don't really need to worry if the
end-user is
This reminds me of ARM-17 that I tried to model after
Haskell/Python/Clojure https://github.com/puppetlabs/armatures/pull/64 . It
stalled out due to lack of time, though it may have some relevant content.
-Hunter
On Tue, Feb 10, 2015 at 12:44 PM, Heck, Walter walterh...@olindata.com
wrote:
Hi Trevor,
On Tue, Feb 10, 2015 at 9:17 PM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
Walter: This would be nice, but variables are the...uh...variable here.
Many people only expose the variables that they need while others expose
every variable they can find. It would be an interesting
On 2015-10-02 21:17, Trevor Vaughan wrote:
To Henrik: Yes, this make sense, it would be nice to have some easy way
to keep the purely Puppet DSL portions separate though.
Yeah, but that is the way it works - so way to much to change to make
that happen.
I guess it would be possible to have
Hi Henrik,
On Tue, Feb 10, 2015 at 9:30 PM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:
On 2015-10-02 19:52, Walter Heck wrote:
I'm personally more of a fan of what some programming languages call
interfaces; a sort of contract if you will that a module implements.
Yes that is
To Henrik: Yes, this make sense, it would be nice to have some easy way to
keep the purely Puppet DSL portions separate though.
Walter: This would be nice, but variables are the...uh...variable here.
Many people only expose the variables that they need while others expose
every variable they can
On 2015-10-02 19:52, Walter Heck wrote:
I'm personally more of a fan of what some programming languages call
interfaces; a sort of contract if you will that a module implements.
Yes that is good - does not solve the issue of modules having the same
name though - either the module name must
12 matches
Mail list logo
