Which cause errors (multiple definitions largely). One solution is to explicitly say "include class/*.pp" (if all the class files you want to pick up are in fact .pp files). Since the backup suffix goes at the very end, backup files fail to match the more specific patter; and people reading the code will clearly see that only .pp files are being included. All the examples show just "include class/*", so I was using that until I started getting errors. I deduce that none of the heavy contributors have backup files enabled :-). Since I come from a TOPS-20 background, I''m used to the idea of having the last few versions of a file I saved be available in the directory; and using ls switches and bash switches I hide them from myself most of the time, so they don''t make my directories too messy to bear (as *I* see them). I''m not sure anything should be changed; I''m posting so anybody searching for this "problem" might find information. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Peter Meier
2008-Oct-03 15:26 UTC
[Puppet Users] Re: Include class/* picks up backup files
Hi> Which cause errors (multiple definitions largely). > > One solution is to explicitly say "include class/*.pp" (if all the > class files you want to pick up are in fact .pp files). Since the > backup suffix goes at the very end, backup files fail to match the > more specific patter; and people reading the code will clearly see > that only .pp files are being included. > > All the examples show just "include class/*", so I was using that > until I started getting errors. I deduce that none of the heavy > contributors have backup files enabled :-). Since I come from a > TOPS-20 background, I''m used to the idea of having the last few > versions of a file I saved be available in the directory; and using ls > switches and bash switches I hide them from myself most of the time, > so they don''t make my directories too messy to bear (as *I* see > them). > > I''m not sure anything should be changed; I''m posting so anybody > searching for this "problem" might find information.how about a scm? -> no backups in the folders, version control, multiple ppl can work on the manifests, and many more advantages! greets pete --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Luke Kanies
2008-Oct-03 17:16 UTC
[Puppet Users] Re: Include class/* picks up backup files
On Oct 3, 2008, at 10:22 AM, dd-b wrote:> > Which cause errors (multiple definitions largely). > > One solution is to explicitly say "include class/*.pp" (if all the > class files you want to pick up are in fact .pp files). Since the > backup suffix goes at the very end, backup files fail to match the > more specific patter; and people reading the code will clearly see > that only .pp files are being included. > > All the examples show just "include class/*", so I was using that > until I started getting errors. I deduce that none of the heavy > contributors have backup files enabled :-). Since I come from a > TOPS-20 background, I''m used to the idea of having the last few > versions of a file I saved be available in the directory; and using ls > switches and bash switches I hide them from myself most of the time, > so they don''t make my directories too messy to bear (as *I* see > them). > > I''m not sure anything should be changed; I''m posting so anybody > searching for this "problem" might find information.I agree with Peter that an SCM is the right answer for backup files -- if you''re not using one, um, you make some kind of sign to ward off evil and adopt one immediately. Additionally, I highly recommend against the old-style ''class'' directory -- IMO, it''s been entirely superceded by modules. -- If computers get too powerful, we can organize them into a committee -- that will do them in. -- Bradley''s Bromide --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 3, 10:26 am, Peter Meier <peter.me...@immerda.ch> wrote:> Hi > > > > > Which cause errors (multiple definitions largely). > > > One solution is to explicitly say "include class/*.pp" (if all the > > class files you want to pick up are in fact .pp files). Since the > > backup suffix goes at the very end, backup files fail to match the > > more specific patter; and people reading the code will clearly see > > that only .pp files are being included. > > > All the examples show just "include class/*", so I was using that > > until I started getting errors. I deduce that none of the heavy > > contributors have backup files enabled :-). Since I come from a > > TOPS-20 background, I''m used to the idea of having the last few > > versions of a file I saved be available in the directory; and using ls > > switches and bash switches I hide them from myself most of the time, > > so they don''t make my directories too messy to bear (as *I* see > > them). > > > I''m not sure anything should be changed; I''m posting so anybody > > searching for this "problem" might find information. > > how about a scm? -> no backups in the folders, version control, multiple > ppl can work on the manifests, and many more advantages!For me, source control doesn''t address the same problem. I''m using source control on my puppet files collection, but I periodically need access to old versions intermediate between when I have now and what I last committed. Except for Sun''s old (and otherwise disastrous) NSE and a small-company product called DRTS that I don''t think exists any more either, I haven''t run into a version-control system that handles that case decently. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Brian Mathis
2008-Oct-03 22:00 UTC
[Puppet Users] Re: Include class/* picks up backup files
On Fri, Oct 3, 2008 at 5:24 PM, dd-b <illegalname@gmail.com> wrote:> On Oct 3, 10:26 am, Peter Meier <peter.me...@immerda.ch> wrote: >> Hi >> >> > Which cause errors (multiple definitions largely). >> >> > One solution is to explicitly say "include class/*.pp" (if all the >> > class files you want to pick up are in fact .pp files). Since the >> > backup suffix goes at the very end, backup files fail to match the >> > more specific patter; and people reading the code will clearly see >> > that only .pp files are being included. >> >> > All the examples show just "include class/*", so I was using that >> > until I started getting errors. I deduce that none of the heavy >> > contributors have backup files enabled :-). Since I come from a >> > TOPS-20 background, I''m used to the idea of having the last few >> > versions of a file I saved be available in the directory; and using ls >> > switches and bash switches I hide them from myself most of the time, >> > so they don''t make my directories too messy to bear (as *I* see >> > them). >> >> > I''m not sure anything should be changed; I''m posting so anybody >> > searching for this "problem" might find information. >> >> how about a scm? -> no backups in the folders, version control, multiple >> ppl can work on the manifests, and many more advantages! > > For me, source control doesn''t address the same problem. I''m using > source control on my puppet files collection, but I periodically need > access to old versions intermediate between when I have now and what I > last committed. Except for Sun''s old (and otherwise disastrous) NSE > and a small-company product called DRTS that I don''t think exists any > more either, I haven''t run into a version-control system that handles > that case decently. >It sounds like you need to be committing more often. There should never be a time when you have a config that you find useful (ie: something that you are satisfied is working) that is not committed. If you find that you need revisions that are "in between" two commits, then you didn''t commit often enough. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 3, 5:00 pm, "Brian Mathis" <brian.mat...@gmail.com> wrote:> On Fri, Oct 3, 2008 at 5:24 PM, dd-b <illegaln...@gmail.com> wrote:> > For me, source control doesn''t address the same problem. I''m using > > source control on my puppet files collection, but I periodically need > > access to old versions intermediate between when I have now and what I > > last committed. Except for Sun''s old (and otherwise disastrous) NSE > > and a small-company product called DRTS that I don''t think exists any > > more either, I haven''t run into a version-control system that handles > > that case decently. > > It sounds like you need to be committing more often. There should > never be a time when you have a config that you find useful (ie: > something that you are satisfied is working) that is not committed. > If you find that you need revisions that are "in between" two commits, > then you didn''t commit often enough.Sometimes I need access to versions more recent than the last commit during periods when the code wasn''t even compiling cleanly (never mind "working") -- clearly such code should *not* be checked in to the public repository! (The thing with NSE and DRTS was that you had a private repository as well as one or more layers of public ones, so I could check into my private one as often as you (and I) think is useful without exposing my intermediate states to the world. I''ve since my previous post seen that GIT, which is actually current and even relevant to Puppet, may also support that working style.) Also, I have to make a conscious decision to commit, and it''s easier to just version the saves than to do manual commits and make up comments and so forth that frequently. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Paul Lathrop
2008-Oct-06 21:11 UTC
[Puppet Users] Re: Include class/* picks up backup files
On Mon, Oct 6, 2008 at 1:17 PM, dd-b <illegalname@gmail.com> wrote:> On Oct 3, 5:00 pm, "Brian Mathis" <brian.mat...@gmail.com> wrote: >> On Fri, Oct 3, 2008 at 5:24 PM, dd-b <illegaln...@gmail.com> wrote: > >> > For me, source control doesn''t address the same problem. I''m using >> > source control on my puppet files collection, but I periodically need >> > access to old versions intermediate between when I have now and what I >> > last committed. Except for Sun''s old (and otherwise disastrous) NSE >> > and a small-company product called DRTS that I don''t think exists any >> > more either, I haven''t run into a version-control system that handles >> > that case decently. >> >> It sounds like you need to be committing more often. There should >> never be a time when you have a config that you find useful (ie: >> something that you are satisfied is working) that is not committed. >> If you find that you need revisions that are "in between" two commits, >> then you didn''t commit often enough. > > Sometimes I need access to versions more recent than the last commit > during periods when the code wasn''t even compiling cleanly (never mind > "working") -- clearly such code should *not* be checked in to the > public repository! (The thing with NSE and DRTS was that you had a > private repository as well as one or more layers of public ones, so I > could check into my private one as often as you (and I) think is > useful without exposing my intermediate states to the world. I''ve > since my previous post seen that GIT, which is actually current and > even relevant to Puppet, may also support that working style.) > > Also, I have to make a conscious decision to commit, and it''s easier > to just version the saves than to do manual commits and make up > comments and so forth that frequently.Although it looks like we aren''t going to be able to convince you, I will add to the argument. I was a heavy user of backup files until I started using an SCM. Then I still used backup files and made the same complaints. Then some people who were smarter/more experienced than me suggested I was using the SCM incorrectly, so I tried it their way for awhile. I''ve never looked back. Seriously. Try it. --Paul --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Brian Mathis
2008-Oct-06 21:12 UTC
[Puppet Users] Re: Include class/* picks up backup files
On Mon, Oct 6, 2008 at 4:17 PM, dd-b <illegalname@gmail.com> wrote:> On Oct 3, 5:00 pm, "Brian Mathis" <brian.mat...@gmail.com> wrote: >> On Fri, Oct 3, 2008 at 5:24 PM, dd-b <illegaln...@gmail.com> wrote: > >> > For me, source control doesn''t address the same problem. I''m using >> > source control on my puppet files collection, but I periodically need >> > access to old versions intermediate between when I have now and what I >> > last committed. Except for Sun''s old (and otherwise disastrous) NSE >> > and a small-company product called DRTS that I don''t think exists any >> > more either, I haven''t run into a version-control system that handles >> > that case decently. >> >> It sounds like you need to be committing more often. There should >> never be a time when you have a config that you find useful (ie: >> something that you are satisfied is working) that is not committed. >> If you find that you need revisions that are "in between" two commits, >> then you didn''t commit often enough. > > Sometimes I need access to versions more recent than the last commit > during periods when the code wasn''t even compiling cleanly (never mind > "working") -- clearly such code should *not* be checked in to the > public repository! (The thing with NSE and DRTS was that you had a > private repository as well as one or more layers of public ones, so I > could check into my private one as often as you (and I) think is > useful without exposing my intermediate states to the world. I''ve > since my previous post seen that GIT, which is actually current and > even relevant to Puppet, may also support that working style.) > > Also, I have to make a conscious decision to commit, and it''s easier > to just version the saves than to do manual commits and make up > comments and so forth that frequently. >Still, it sounds like you need to modify your workflow instead of blaming the revision software. There''s a reason the market has chosen these kinds of revision systems. I think what you need to be doing is: - When you start making changes, make a branch in your RCS - As you make changes, commit each step in that branch. Each commit should only contain discrete parts, like "fixed typo in node name", or "updated apache config to support ssl". Commits should not contain a big chunk of unrelated changes. - Once you have tested and are ready to "release", you merge that branch back into the "main" branch of the repository. It requires discipline and probably some changes to the way you are used to working. Also, it''s common to have files laying around with different versions of intermediate files, etc..., but those should be in your test area and ultimately do not get checked in to the system. Anything that''s left over that you don''t want to check-in should be considered "notes" and maybe filed away in a notebook/txt file and not in the repository or as files junking up the Puppet directories. Look at it this way: the rest of the open source (and many closed source) world uses these types of RCS systems just fine, so either: a) you are much smarter than everyone else and could become a millionaire with your approach - OR - b) you might learn a thing or two by looking at how most other people do it --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 6, 4:11 pm, "Paul Lathrop" <p...@tertiusfamily.net> wrote:> Although it looks like we aren''t going to be able to convince you, I > will add to the argument. I was a heavy user of backup files until I > started using an SCM. Then I still used backup files and made the same > complaints. Then some people who were smarter/more experienced than me > suggested I was using the SCM incorrectly, so I tried it their way for > awhile.Well, I''ve been using source code control systems since, oh, about 1982 I think. I use them for system management and personal projects as well as for work. I''ve used them for single config files and for about 5 million lines of C++ video streaming code. I''ve used them in Massachusetts, Minnesota, and California. I''ve used DEC CMS, SCCS, RCS, CVS, Sun''s NSE, DRTS, Microsoft''s VSS, and Subversion. I''ve used them at Digital Equipment Corporation, Network Systems, and Sun Microsystems (and a bunch of places most people wouldn''t have heard of). I''ve used them for new projects and for next-version development on code more than a decade old and for maintenance. In some cases I''ve been the proponent that took a project into using source control. The fact that I started using source control on TOPS-20 may be relevant; the TOPS-20 filesystem did multiple versions of files inherently (instead of via a naming hack in some utilities the way it''s done in Linux). I view it as a normal, natural, useful capability. Having to think about which levels of change need to be committed all the time is a high-cost high-risk activity. The fact that CVS and Subversion make using temporary branches really ugly and error-prone doesn''t help, either. I haven''t yet encountered any place that uses branches for anything smaller than multi-week sub- projects. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 6, 4:12 pm, "Brian Mathis" <brian.mat...@gmail.com> wrote:> On Mon, Oct 6, 2008 at 4:17 PM, dd-b <illegaln...@gmail.com> wrote: > > On Oct 3, 5:00 pm, "Brian Mathis" <brian.mat...@gmail.com> wrote: > >> On Fri, Oct 3, 2008 at 5:24 PM, dd-b <illegaln...@gmail.com> wrote: > > >> > For me, source control doesn''t address the same problem. I''m using > >> > source control on my puppet files collection, but I periodically need > >> > access to old versions intermediate between when I have now and what I > >> > last committed. Except for Sun''s old (and otherwise disastrous) NSE > >> > and a small-company product called DRTS that I don''t think exists any > >> > more either, I haven''t run into a version-control system that handles > >> > that case decently. > > >> It sounds like you need to be committing more often. There should > >> never be a time when you have a config that you find useful (ie: > >> something that you are satisfied is working) that is not committed. > >> If you find that you need revisions that are "in between" two commits, > >> then you didn''t commit often enough. > > > Sometimes I need access to versions more recent than the last commit > > during periods when the code wasn''t even compiling cleanly (never mind > > "working") -- clearly such code should *not* be checked in to the > > public repository! (The thing with NSE and DRTS was that you had a > > private repository as well as one or more layers of public ones, so I > > could check into my private one as often as you (and I) think is > > useful without exposing my intermediate states to the world. I''ve > > since my previous post seen that GIT, which is actually current and > > even relevant to Puppet, may also support that working style.) > > > Also, I have to make a conscious decision to commit, and it''s easier > > to just version the saves than to do manual commits and make up > > comments and so forth that frequently. > > Still, it sounds like you need to modify your workflow instead of > blaming the revision software. There''s a reason the market has chosen > these kinds of revision systems.I see that kind of differently. Your proposed workflow (below) is working around a weakness that''s unfortunately prevalent in the mainstream version control software today, at some considerable increase in complexity and risk of error.> > I think what you need to be doing is: > - When you start making changes, make a branch in your RCSYeah, if you do that you can of course commit a lot more often. Do the comments from those commits get rolled up into the trunk when you merge back, though? Or do they get lost? I haven''t yet worked someplace that uses that as a normal approach, though I''ve considered trying to introduce it. The problem I see is that CVS and Subversion handle branches sufficiently poorly that it''s kind of a pain to do. And there''s some real risk of merging the wrong stuff, or merging it wrong, since there''s a lot of manual keeping track of things required. I haven''t used GIT, but reading the documentation, I think it may handle things a lot more nicely. [snip stuff I agree with]> Look at it this way: the rest of the open source (and many closed > source) world uses these types of RCS systems just fine, so either: > a) you are much smarter than everyone else and could become a > millionaire with your approach > - OR - > b) you might learn a thing or two by looking at how most other people do itI''ve been learning things from how other people do it for quite a while now. But I haven''t before this met *anybody* or any place that does it the way you describe using current-generation tools, so if "most people" do it that way, it''s news to me. It''s the working style I learned to like with NSE and DRTS, but I haven''t been able to use it since then because of poor tool support. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Digant C Kasundra
2008-Oct-07 18:23 UTC
[Puppet Users] Re: Include class/* picks up backup files
----- "dd-b" <illegalname@gmail.com> wrote:> All the examples show just "include class/*", so I was using that > until I started getting errors.I''m curious which examples these are. Best practice is usually to let autoloading take care of loading class pp files. I was just curious if there was an example on the Wiki that we hadn''t updated or might want to revisit. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
David Schmitt
2008-Oct-08 06:20 UTC
[Puppet Users] Re: Include class/* picks up backup files
[jumping in late, haven''t read the thread] dd-b schrieb:> Having to think about which levels of change need to be > committed all the time is a high-cost high-risk activity.You are 100% right.> The fact that CVS and Subversion make using temporary branches really > ugly and error-prone doesn''t help, either. I haven''t yet encountered > any place that uses branches for anything smaller than multi-week sub- > projects.That''s why the git-people say that svn is broken. In git you cannot work _without_ having a branch. Regards, DavidS --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 8, 1:20 am, David Schmitt <da...@dasz.at> wrote:> [jumping in late, haven''t read the thread] > > dd-b schrieb: > > > Having to think about which levels of change need to be > > committed all the time is a high-cost high-risk activity. > > You are 100% right. > > > The fact that CVS and Subversion make using temporary branches really > > ugly and error-prone doesn''t help, either. I haven''t yet encountered > > any place that uses branches for anything smaller than multi-week sub- > > projects. > > That''s why the git-people say that svn is broken. In git you cannot work > _without_ having a branch.I thought that''s what their materials were saying (quick reads, and I haven''t played with the actual software). I can get behind that approach. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 7, 1:23 pm, Digant C Kasundra <dig...@stanford.edu> wrote:> ----- "dd-b" <illegaln...@gmail.com> wrote: > > All the examples show just "include class/*", so I was using that > > until I started getting errors. > > I''m curious which examples these are. Best practice is usually to let autoloading take care of loading class pp files. I was just curious if there was an example on the Wiki that we hadn''t updated or might want to revisit.One of them is http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#id35 -- the basic example of "import" in the language tutorial. I think that''s where I picked it up. --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Peter Meier
2008-Oct-09 07:06 UTC
[Puppet Users] Re: Include class/* picks up backup files
Hi>>> All the examples show just "include class/*", so I was using that >>> until I started getting errors. >> I''m curious which examples these are. Best practice is usually to let autoloading take care of loading class pp files. I was just curious if there was an example on the Wiki that we hadn''t updated or might want to revisit. > > One of them is http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#id35 > -- the basic example of "import" in the language tutorial. I think > that''s where I picked it up.updated. btw: it''s a wiki ;) greets pete --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 9, 2:06 am, Peter Meier <peter.me...@immerda.ch> wrote:> Hi > > >>> All the examples show just "include class/*", so I was using that > >>> until I started getting errors. > >> I''m curious which examples these are. Best practice is usually to let autoloading take care of loading class pp files. I was just curious if there was an example on the Wiki that we hadn''t updated or might want to revisit. > > > One of them ishttp://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#id35 > > -- the basic example of "import" in the language tutorial. I think > > that''s where I picked it up. > > updated. > > btw: it''s a wiki ;)Ah; hadn''t occurred to me I might have change access at this point, so I didn''t test it. So I''ll keep it in mind, then! --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---