install_from cookbook should be renamed to "ark" #107

Closed
bryanwb opened this Issue Feb 21, 2012 · 7 comments

3 participants

@bryanwb

even with hippie-expand install_from_release takes a lot to type, and i have hippie-expand in my irc client

further, the lwrp should be just "ark"

If this change is accepted, I promise to shut my mouth about long names and to promise eagerly push back all my changes to that lwrp, as I have already made a #

https://github.com/bryanwb/cookbooks/tree/master/ark

and I promise to write a really beautiful README.md for ark as I have already put a fair amount of text into it

https://github.com/bryanwb/cookbooks/blob/master/ark/README.md

btw, an ark is an archive but kewler ;)

@pcn

How does this tie in with your java ark LWRP?

@bryanwb
@temujin9

Okay, so here's the breakdown as I see it:

  • I like that the install_from recipes are getting some outside love. They're important enough that having more than just our eyes and hands on it is a very good thing.
  • The naming change makes this a breaking change to our existing architecture. I'll have to go through all of the cookbooks using install_from and rework them to use ark instead. That makes it a difficult thing to adopt where we're at in our release cycle.
  • You say you don't yet support ant, make, or setup.py. Of those, at least ant and make are pretty vital to our adoption.
  • I'm not interested in juggling the two different paradigms; I'm doing that enough elsewhere, and I've only got a limited head-space to hold all of our architecture in.

So, we've got two distinct possibilities for inclusion:
1. Ark gets ant and make support, and we examine it closely for inclusion in Ironfan 4.0 (or the next major release after its ready).
2. Like 1, but you also wrap the install_from calls for backwards compatibility, and we look closely at including it into Ironfan 3.2 (or the next minor release after it's ready). Ideally, this wrapper would be a drop-in replacement for the install_from cookbook, so that we don't have to fiddle with dependencies on other cookbooks.

Are either of those interesting to you? It would mean a bit more work on your end, but would ensure that our install_from and your ark don't diverge yet further, which ultimately means more eyes and hands on your work.

@bryanwb

It doesn't yet support ant or setup.py because I totally reworked install_from_release from an LWRP into a Library. I find the code much easier to maintain that way. I to have basic support for make but not ant, I dont' think it would be terribly difficult to add. I am very happy that I now have integration tests through chef-minitest that I can test with Vagrant or Toft

https://github.com/bryanwb/chef-ark/tree/master/libraries

you should be happy to know that ark in now part of the core opscode cookbooks. That means more eyeballs and pull requests for this important body of code.

As for #2 I think we could alias methods for the purpose of backward compatibility. I do plan on adding make and ant support sooner than later. I manage a java shop and everything i do hangs off ark.

coming to chefconf? it would be great to talk w/ you about ark there.

@temujin9

I will indeed be at ChefConf. Look forward to talking more about this there.

@temujin9

Where does this stand? I can't promise I'll move it in with alacrity, but it'd be nice to consider as we get into refactoring our cookbooks.

@temujin9

Closing for now. @bryanwb, feel free to comment with status, and we'll reopen if appropriate.

@temujin9 temujin9 closed this Sep 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment