On Jan 30, 2:51 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> Hi,
>
> On 01/28/2012 04:35 PM, Trevor Vaughan wrote:> Drawbacks:
>
> > * Requires the user to have an explicit working knowledge of all
>
> modules and namespaces> * Adds a lot of random logic to the code (unless it
> becomes a
>
> metaparam of some sort)
>
> You skipped the most important drawback: Commitment to parameterized
> classes. The fact that there can be only one place that includes those
> classes, and that this singular place must have the whole picture of
> what requirements are met, is conceivably a show stopper from my point
> of view.
+1
> This will work for people that have a functional ENC, I guess, but
> should that be a requirement for using Forge modules?
>
> Furthermore, how can modules hope to ever interoperate like this? If all
> module classes get parameterized, it will be outright impossible for one
> module to ever include another module's classes.
> Say module A includes class B::C. As soon as a user installs module A in
> addition to B, they have to clean their manifests of inclusions of B::C.
Right. The approach depends on using class parameters to pass
requirements, but it depends on classes being *un*parameterized to
apply those requirements -- catch-22. There is a solution to that
particular problem, however: define requirements via external
[meta]data instead of via parameters.
That's not to say I like the proposal, however. I don't. In fact I
think it's completely inside-out. Classes should *know* what other
classes they depend upon; they should not need to be told.
Moreover, I don't see what is gained by passing requirements as
parameters rather than, say, having the user separately declare
optional classes that carry the same information. For example,
instead of a structure requiring this:
class { 'foo': reqs => ['bar'] }
it should be possible to structure a module's classes so that you can
do this instead:
include 'foo::bar'
include 'foo'
(perhaps in the opposite order).
> On 01/29/2012 07:39 AM, Brian Gupta wrote:
>
> > It frightens me a bit that I think the "correct" solution, will be to
> > replicate what the distros are doing in Puppetforge. Basically turning
> > puppetforge into a massive cross distro metadata repo, with very strict
> > contribution standards and rules. This would involve strong rules for
> > curated modules that would require manpower to vet (and to
> > contribute the modules).
>
> I honestly don't see the problem. Imagine CPAN was limited to downloads
> of tarballs from the website (or even souce control checkouts). I
> disbelieve it would be as significant today as it has become.
> The same goes for Ruby Gems and all such systems.
>
> As this seems to be a recurring theme: Am I wrong to compare these to
> the Forge?
Yes and no.
On one hand, clearly there are structural similarities between, say,
Puppet modules and Perl modules. The Forge serves a similar role for
the former to the role CPAN serves for the latter. I can totally see
the usefulness of tools for automatically installing and removing
Forged Puppet modules.
On the other hand, there are several problems with adopting such an
approach to solve the Puppet module dependency issue, among them:
1) The Forge doesn't address the problem AT ALL as it now stands. The
relevant resource that package management systems offer is not the
packages themselves (which the Forge has), but rather the metadata
database that each system relies on. Defining, building, and
maintaining such a database would be a massive and ongoing endeavor,
quite separate from developing and managing the Puppet and module
codebases.
2) A package management system would only work around the problem, not
solve it, and then only among modules from the same repository.
3) In fact, it would not really be the package management system
itself that made anything work. Instead, authors of Forge modules
would still need to find some way to make their modules interoperate,
and Forge curators would need somehow to ensure that they did. All
the management software would really contribute is a dependency-aware
ability to automatically install/remove packages. The system overall
would provide a promise that the particular modules it contains all do
work together, but that's altogether different from a means by which
anyone -- the Forge or otherwise -- can fulfill such a promise.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
