Issue #19019 has been updated by Adrien Thebo.
I think that a `createdby` parameter would create a lot more problems than it would be worth. If the File resource is actually calling a command to set the contents, then this is going to take all of the logic of the Exec type, and put it in the File type. For instance, if the File type is populating the contents, it would have to deal with the following: * What user/group is the command run as? This could definitely differ from the owner and group of the File, so we can't just use that. * What is the current working directory of the command? * What environment variables are set for the invocation of the command? * How should the command be executed? with `bash -c`? With Ruby's `Kernel.exec` ? * How is the content of the file updated? Is the command run once, and only run once? If the `exec` and `file` resources are separate, these are easy to deal with. If you merge them, it gets ugly fast. If the `created_by` param was added to the File type, it would entail copying pretty much all of the behavior of the Exec type to support a reasonable range of use cases. Instead of having a define like `execfile` that wraps those two things together, this would move that logic into the Ruby layer. The outcome would be that manifests would be a couple lines shorter and a bit prettier at the expense of really complicating the File type, which is already pretty gnarly. If there's another reason to add this beyond elegance, that could certainly change my opinion of this feature request. However my understanding is that this would improve a simple use case, and would be pretty costly in terms of implementation and maintenance. If there is something that does need this tight coupling, then this could be implemented as a custom type and provider. I wrote a type and provider for [Debian alternatives](https://github.com/adrienthebo/puppet-alternatives), and really it's a glorified exec. However to the end user, it's a much more robust resource than a straight exec; it has documentation, better validation works with `puppet resource`, et cetera. If someone really needs this tight coupling and a defined type is out of the question then it can probably be implemented as a custom type and provider that's built for the job. I think this is about as close to the best of both worlds as we can get. ---------------------------------------- Feature #19019: Add "createdby" parameter to "file" type https://projects.puppetlabs.com/issues/19019#change-90607 * Author: Richard K. Miller * Status: Needs More Information * Priority: Normal * Assignee: eric sorenson * Category: language * Target version: * Affected Puppet version: * Keywords: * Branch: ---------------------------------------- I occasionally use **exec** + **creates** to install a file not easily available any other way. <pre> exec { "curl -s https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin": creates => "/usr/local/bin/composer.phar", } </pre> If there were a **createdby** parameter on the **file** type, I could reverse the clauses like this: <pre> file { "/usr/local/bin/composer.phar": createdby => "curl -s https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin", } </pre> ...which would mean I could use **file** parameters like **mode**, **owner**, **group**, etc. <pre> file { "/usr/local/bin/composer.phar": createdby => "curl -s https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin", mode => 0755, owner => "root", } </pre> The **createdby** parameter would be somewhat similar to the **content** parameter except that it would create the file by running a local command instead of passing the content. This may also help solve Issue #2762 and Issue #2546 . -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
