customink-webops / hostsfile

Easily manage your hosts file with Chef
Apache License 2.0
155 stars 82 forks source link

hostsfile gem #57

Closed tnarik closed 10 years ago

tnarik commented 10 years ago

Hi,

I created a 'hostsfile' gem extracting libraries code to its own package, without dependencies on Chef, so that it can be used by other tools, ruby code scripts, etc...

Would you be interested in someone creating a pull request to add that implementation/package of code instead of the 'libraries'?

Cheers.

sethvargo commented 10 years ago

@tnarik you copied code directly from this project and re-assigned copyright to yourself. The original license file and headers have been removed and replaced with your own. Could you please restore the original headers as soon as possible? I understand this may not have been your intent. If you wish to keep the changes, you must keep the original copyrights intact. You can assign future copyright modifications to yourself. You can read more about it in this StackOverflow post.

If you would like to improve the existing codebase with your changes, I would gladly review a Pull Request.

As for adding a gem dependency - because this is an LWRP, this would require the use of chef_gem to install the dependency at load time instead of runtime. This causes a really strange dependency loop that I have described in my "Using gems with Chef" blog post. I much prefer the vendored pattern for this reason, because it eliminates these problems. I maintain a Chef cookbook that is both a gem and cookbook (chef-sugar), and the implications of maintaining both is very difficult.

tnarik commented 10 years ago

I'll add the license to the specific files, sure. I was just trying to simplify it by adding the LICENSE to the gem as a whole (given that the LICENSE is the same) and preserving the copyright in the files extracted from the customink-web ops project, including a reference to that. But if you think the verbosity of adding the LICENSE to every file is preferred, I have no issue at all. As to the name of the project, this is the only hosts file gem and it has no link whatsoever with Chef, so I don't see the point in changing the name. They are available in different spaces, installation and repositories from which they might be available are different and furthermore I doubt 'hostsfile' as such can be a copyrighted name.

What I got from your response is that you would prefer not making the cookbook dependent on a gem, which I understand, so I won't waste anytime on a PR. If you change your mind, let me know. I would have preferred if the gem had already been available, as the implementation is sound and covers all use case I required, even if there was a bit more of code than needed.

Cheers.

On 19 Aug 2014, at 22:36, Seth Vargo notifications@github.com wrote:

@tnarik you copied code directly from this project and re-assigned copyright to yourself. The original license file and headers have been removed and replaced with your own. Could you please restore the original headers as soon as possible? I understand this may not have been your intent, but if you do wish to re-assign copyright to yourself, I believe you need to change the name of the project entirely, as dictated by the Apache 2.0 License.

If you wish to keep the changes, you must keep the original copyrights intact. You can assign future copyright modifications to yourself. You can read more about it in this StackOverflow post.

If you would like to improve the existing codebase with your changes, I would gladly review a Pull Request.

As for adding a gem dependency - because this is an LWRP, this would require the use of chef_gem to install the dependency at load time instead of runtime. This causes a really strange dependency loop that I have described in my "Using gems with Chef" blog post. I much prefer the vendored pattern for this reason, because it eliminates these problems. I maintain a Chef cookbook that is both a gem and cookbook (chef-sugar), and the implications of maintaining both is very difficult.

— Reply to this email directly or view it on GitHub.

sethvargo commented 10 years ago

I was just trying to simplify it by adding the LICENSE to the gem as a whole (given that the LICENSE is the same)

Part of the Apache 2.0 license requires the license headers. I agree - it's weird, but a requirement nonetheless. :smile:

tnarik commented 10 years ago

I reincoraporated the headers with my addition for the modifications. As I said before, if at some point you think using the gem (or a gem you create) makes more sense, let me know. As for PR's, the only thing I see is the removal of 4 lines of code that cannot be called, to improve reports on testing coverage, but it is not an issue at all.

sethvargo commented 10 years ago

Thanks :smile: