Separate repository for example packages?

[stuartellis]

I'm raising this as an idea to see what you think, but would also be willing to work on it if you think that it's worthwhile.

The benefit would be that it would give people an obvious place to look for packages, and to contribute back. I've recently started using Sprinkle, putting together a small reusable stack, and have found a lot of really good stuff in different examples and stacks, but many of them seem to be incomplete or no longer maintained.

In any event, thank you for Sprinkle - it has been a real pleasure to use.

[joshgoebel]

Someone else suggested something like a Gemfile for sprinkles so you could pull sprinkles from all over the net easily into your packages folder or some such. I like the idea of a central repository (like homebrew, for example) for building such a thing is really a project in it's own right. :) Feel free to take a stab at it... if we start to get something really nice it could become official.

[stuartellis]

Thanks for the reply - I've now read the discussion on issue #70.

The biggest issue that I hit when thinking about this is having a convention for where to put templates or other assets that go with a particular package - once a package gets beyond something simple it needs at least one template to build a configuration file, and Sprinkle doesn't give a convention for storing those.

For example, this package enables automatic software updates on Debian and Ubuntu, but it needs to put a config file on the target system:
https://github.com/stuartellis/spritz/blob/master/packages/debian/apt_enable_auto_upgrades.rb

In this case, the config is simple enough that the template could be in-lined in the package file itself, which would keep things simple.

For more complex stuff, the package might effectively be a directory that holds the main package file and the other assets. OR the answer could be "to keep Sprinkle light and flexible, packages must always be single files".

If I had an "official" opinion on that, I'd definitely be happy to start building out a GitHub repository of examples and then help work on whatever integration into Sprinkle itself seems appropriate.

[joshgoebel]

Another thought is should their be one big master repository (homebrew, etc) or should sprinkle powder files be wrapped up as ruby gems... sprinkle-rails, sprinkle-mysql... then you'd just install the gems you need and require them in your sprinkle recipe.

[stuartellis]

Hmm, well the initial idea that I had was to start with one big repository on GitHub. People could then fork from it, and easily submit their own packages as pull requests. It would be very easy to get the ball rolling and start getting contributions that way.

The thing that I'm conscious of is that tools like Chef have hundreds of packages in their repositories, mostly submitted as drive-by contributions rather than being done by the core developers.

More fuzzily, it occurred to me that the repository could include a Rakefile to do any useful tasks, like create new package files from a standard template. Thinking about, this Rakefile could also have tasks to export sets of packages into gems.

[joshgoebel]

I think one should first decide if gems are a good idea. Hate for every tool that needs a packaging system to pollute the rubygems namespace, though I have no idea if they care.

How do you combat drive-by contributions?

[stuartellis]

I agree about the namespace - Debian has the same problem with a zillion mysql-whatever packages.

I was thinking that the repository could have a Rake task that builds a gem from a given list of packages, and drop the gem into a subdirectory of the cloned repository, but wouldn't submit anything to the public RubyGems server. So people could use the task to build themselves gems for whatever set of packages they want - joshs-mysql.gem, joshs-webserver-packages.gem etc. That could evolve or be replaced by a cleverer tool over time.

WRT to drive-by contributions... Years ago I worked on documentation, and the way that we got people to start contributing was to use a Wiki, let them put in whatever, and have a few interested "gardeners" keep it tidy. Some people got into the habit of contributing and got better, others just put their little bit of knowledge in and wandered off. Initially we had insisted that people submit full documents in the proper format and commit to maintaining them, and we got no useful contributions at all.

[joshgoebel]

Closing this, please lets continue the discussion exclusively in #70.