Hi All, just before I''ll consider writing a script, Does anyone has a good way to auto indent, or better fix indent for exists file? Thanks, Ohad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Puppet comes with a syntax file for Vim. It understands the Puppet language, and provided you ''set autoindent'' the indentation will be good, and you can reindent with the = command on a selection. -- Jean-Baptiste Quenot http://jbq.caraldi.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 -~----------~----~----~----~------~----~------~--~---
Hi, I''m aware of vim support for indentation, and also for setfiletype puppet in vim. I don''t know if you tried to ''='' on a whole file, it doesn''t really work. What I''m looking is to have a way to standardize the way my puppet manifest looks like, since we have multiple authors each one with his own editor (tab vs spaces etc).... Thanks, Ohad On Sun, Jul 20, 2008 at 10:50 PM, Jean-Baptiste Quenot <jbq@caraldi.com> wrote:> > Puppet comes with a syntax file for Vim. It understands the Puppet > language, and provided you ''set autoindent'' the indentation will be > good, and you can reindent with the = command on a selection. > -- > Jean-Baptiste Quenot > http://jbq.caraldi.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 Jul 20, 8:20 pm, "Ohad Levy" <ohadl...@gmail.com> wrote:> > What I''m looking is to have a way to standardize the way my puppet manifest > looks like, since we have multiple authors each one with his own editor (tab > vs spaces etc)....There''s no set standard, of course. The wiki StyleGuide page prefers 4 spaces: http://reductivelabs.com/trac/puppet/wiki/StyleGuide Though I didn''t see specific recommendation/reference to 4 spaces, just noticed that in the example manifests used. I personally prefer 4 spaces, but where I work the standard is 2 spaces. It was easy enough to modify my .vimrc to accommodate. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
jtimberman <grumpysmurf@gmail.com> writes:> On Jul 20, 8:20 pm, "Ohad Levy" <ohadl...@gmail.com> wrote: >> >> What I''m looking is to have a way to standardize the way my puppet manifest >> looks like, since we have multiple authors each one with his own editor (tab >> vs spaces etc).... > > There''s no set standard, of course. The wiki StyleGuide page prefers 4 > spaces: > > http://reductivelabs.com/trac/puppet/wiki/StyleGuide > > Though I didn''t see specific recommendation/reference to 4 spaces, > just noticed that in the example manifests used.The ruby-mode file for Emacs, supplied with puppet, prefers 2 space indentation, for what that is worth. Regards, Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
José González Gómez <jose.gonzalez.gomez@gmail.com> writes:> On 21 jul, 04:20, "Ohad Levy" <ohadl...@gmail.com> wrote: >> >> I''m aware of vim support for indentation, and also for setfiletype >> puppet in vim. I don''t know if you tried to ''='' on a whole file, it >> doesn''t really work. >> >> What I''m looking is to have a way to standardize the way my puppet >> manifest looks like, since we have multiple authors each one with his >> own editor (tab vs spaces etc)....If you forgive my saying so, this is a social problem rather than a technical problem. Solve it by talking to your authors and getting agreement on appropriate coding standards. This is important, because ...> I remember from my Java coding days that there were a few code > "beautifiers" that let you configure every aspect of code presentation > (not just indentation) and then reformat a whole project. Even Eclipse > introduced a long time ago a code formatter that kept your code > correctly formatted according to your coding standards, using a coding > style definition that could be installed in every developer machine. > Maybe you could take a look to some of them and try to adapt it to > puppet code (don''t know if it''s possible) > > I don''t know if people would appreciate such a thing regarding puppet,... this technical approach is going to cause you a universe of grief. The first reason is that when you apply the code reformatting tool you just created a commit that rewrote (or most) of the history under your user ID. This means that tools like blame/annotate can''t determine who was responsible for individual parts of the code as effectively. It also means that all your authors have a single point in time around which they need to restructure all their outstanding work -- they have to merge this new change in, in one big burst of effort.> but I think these kinds of tools are great for improving code > readability, as all the code for a project (team? company?) is always > formatted the same way and after some time you get used to it.This isn''t as bad as what this seems to imply, though, which is running this sort of tool on a regular basis. Ouch! Every time you reformat code you cause extra work for the other authors, which is not going to be appreciated. Worse, if you don''t get agreement on this beforehand imagine what your other authors will do: because you reformatted code, they will feel they, also, can reformat it. So, they run the reformatter to get their own preferred style uniformly applied across the codebase, you change it back, and it all ends up with someone getting stabbed in a back alley.[1] So, solve the *social* problem with social tools, not technical ones. If you do that, and it seems *really* important -- and you can justify the technical cost -- then use a reformatter *once* on your codebase. Regards, Daniel Mostly, though, just don''t do it. Footnotes: [1] This is probably an exaggeration, since most developers and sysadmins are too lazy to actually stab you. ;) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> So, solve the *social* problem with social tools, not technical ones. > > If you do that, and it seems *really* important -- and you can justify > the technical cost -- then use a reformatter *once* on your codebase. >I agree with you fully :) the only technical thing I could think of is to use a hook in the version control to format the file before saving. Thanks, Ohad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I don''t agree with you (although I agree with some of the things you say)... comments inline On 26 jul, 04:34, Daniel Pittman <dan...@rimspace.net> wrote:> José González Gómez <jose.gonzalez.go...@gmail.com> writes: > > > On 21 jul, 04:20, "Ohad Levy" <ohadl...@gmail.com> wrote: > > >> I''m aware of vim support for indentation, and also for setfiletype > >> puppet in vim. I don''t know if you tried to ''='' on a whole file, it > >> doesn''t really work. > > >> What I''m looking is to have a way to standardize the way my puppet > >> manifest looks like, since we have multiple authors each one with his > >> own editor (tab vs spaces etc).... > > If you forgive my saying so, this is a social problem rather than a > technical problem. Solve it by talking to your authors and getting > agreement on appropriate coding standards. >No, this is a social AND a technical problem. First of all, I wasn''t talking about a group of independent developers contributing to a project, I was talking about a team inside a company, with a clear leadership and somebody that stablishes standard workflows and practices, maybe company wide. In this case there is no agreement, there is training of the team to comply with company/team standards.> This is important, because ... > > > I remember from my Java coding days that there were a few code > > "beautifiers" that let you configure every aspect of code presentation > > (not just indentation) and then reformat a whole project. Even Eclipse > > introduced a long time ago a code formatter that kept your code > > correctly formatted according to your coding standards, using a coding > > style definition that could be installed in every developer machine. > > Maybe you could take a look to some of them and try to adapt it to > > puppet code (don''t know if it''s possible) > > > I don''t know if people would appreciate such a thing regarding puppet, > > ... this technical approach is going to cause you a universe of grief. > > The first reason is that when you apply the code reformatting tool you > just created a commit that rewrote (or most) of the history under your > user ID. > > This means that tools like blame/annotate can''t determine who was > responsible for individual parts of the code as effectively. > > It also means that all your authors have a single point in time around > which they need to restructure all their outstanding work -- they have > to merge this new change in, in one big burst of effort. >This isn''t true, as long as you always use the code reformatting tool before commiting your changes, and this tool has been used from the beginning (or at least from some point) of the project.> > but I think these kinds of tools are great for improving code > > readability, as all the code for a project (team? company?) is always > > formatted the same way and after some time you get used to it. > > This isn''t as bad as what this seems to imply, though, which is running > this sort of tool on a regular basis. Ouch! > > Every time you reformat code you cause extra work for the other authors, > which is not going to be appreciated. >First of all, code must be reformatted either by authors before they commit or be automatically formatted by a hook in the version control software. I don''t see how this can cause extra work for the other authors, as all the code is being formatted the same way.> Worse, if you don''t get agreement on this beforehand imagine what your > other authors will do: because you reformatted code, they will feel > they, also, can reformat it. >As I told you before, I was talking about a scenario were practices are imposed rather than agreed. I ask you to think about the other extreme: let''s say you have a large team of developers all working in the same project and each of them using their own coding "standards". Believe me, even if the code is good from the thecnical point of view, the resulting code is a mess and really hard to read.> So, they run the reformatter to get their own preferred style uniformly > applied across the codebase, you change it back, and it all ends up with > someone getting stabbed in a back alley.[1] > > So, solve the *social* problem with social tools, not technical ones. >Although I agree with you that this is (in part) a social problem, I don''t believe there are only either social or technical problems. All problems have social and technical aspects. For example, both you and Ohad seem to imply that version control is a technical problem, and that isn''t my experience at all. I have found developers commiting uncompilable code at the end of every day because they thought of the version control system as some kind of backup of their work, or developers commiting code without updating their working copy before to check if their code was compiling with the latest additions. So version control software is a tool that solves a technical problem, but you have to train people to correctly use the tool, or to use it the way you want them to use it, and this is the social aspect. Code formatting works the same way: you have a social aspect of agreement or training about coding standards, and then you have the technical problem of getting everybody to comply with the imposed or agreed standard, and here''s where a code formatting tool comes in handy. And please, don''t tell me you can do this without a code formatting tool. If you do: 1. Please, take a look at whatever Java code formatting tool you want, and tell a developer to check for every single aspect the tool checks... don''t be surprised if the developer looks atonished 2. I''ll tell you to drop your control version system... after all if you''re man enough to format ALL the code EXACTLY the same way, I guess you''ll be man enough to merge by hand in a shared directory ;o)> If you do that, and it seems *really* important -- and you can justify > the technical cost -- then use a reformatter *once* on your codebase. >I don''t think this is a valid solution at all, as code reformatting is not for improving readability for someone that eventually happens to read the code, is for improving readability for people working daily on the code, who has agreed or been trained on a coding standard. Best regards Jose --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---