Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update readme #3

Closed
professor opened this issue Jan 25, 2016 · 9 comments
Closed

Update readme #3

professor opened this issue Jan 25, 2016 · 9 comments

Comments

@professor
Copy link
Contributor

Maybe the readme could explain how this is different than sprout-wrap and why we should be using this instead of the normal way we setup machines at Pivotal.

I feel like I'm missing some context

@spilth
Copy link
Contributor

spilth commented Jan 25, 2016

Right now it's still an experiment. Here are my reasons for creating it, though:

  • The current sprout-wrap project doesn't work on a fresh machine. I'm still cataloging the problems but most everybody who uses it ends up running into an issue with it. This is a bad experience, especially in front of client developers.
  • I think sprout-wrap is a bad name for the project. It provides no information about what it actually does. workstation-setup is pretty straightforward in explaining what the project does.
  • IMHO, the sprout-wrap project is overly complex. If I have to not only fork the repo but also the repos it relies on, that's a lot to explain to somebody and ask them to do. It also makes it non-trivial to fix things.
  • It's not immediately clear how to create and add your own sprout project.
  • workstation-setup only requires git, bash and Ruby which are all available on a machine by default. Then all I have to do is run one bash script. This could be remedied in sprout-wrap by combining steps 3 and 4 of the readme into a bash script.

@LukeWinikates
Copy link

When sprout was introduced, part of its mandate was to simplify maintaining Pivotal's base developer machine images. If @spilth's first comment is true, I'm curious about the origins of the current Yosemite image.

I've forked sprout-wrap at least twice, but I don't believe I've ever forked any of the cookbooks in order to run sprout-wrap. I don't think that's the intended use.

Other than that, on 3 and 4, I think it's only fair to say that sprout's a pretty ambitious project and Chef brings some complexities. Sometimes I think that what Chef adds in convenience it takes away in terms of layers of abstraction. Still, the idempotence of the chef recipes is really nice.

I wish y'all luck. Hope you'll engage with @hiremaga & the sprout contributors when you think the time is right, since you're pursuing the same goals.

@kejadlen
Copy link
Contributor

I spent some time earlier last week trying to get sprout-wrap to work on the current Yosemite image. There were three main issues that I ran into:

  1. chef-cookbooks/homebrew#87: The Homebrew cookbook was broken due to Homebrew changing how it managed its config. This seems to have just been fixed.
  2. sprout-homebrew#22: Cask is now bundled with Homebrew. This completely breaks the recipe for me on new machines.
  3. Installing Ruby 2.2.3 through rbenv install doesn't work through Chef, although it does locally. I wasn't able to nail down a fix, but it appears to be related to why RVM has patches for installing Rubies. I tried fiddling with GEM_HOME and GEM_PATH in sprout-rbenv to fix is, but eventually gave up.

There may have been some other random issues, but I mostly was able to successfully run sprout-wrap after taking care of the above issues by forking sprout-wrap and sprout-homebrew.

I use Ansible for my personal system configuration, which has the right balance of simplicity and power for my needs.

@professor
Copy link
Contributor Author

@spilth thank you for clarifying the purpose of this project.

I've used sprout wrap a few times. When it works, I love it. On a recent project, I needed to customize the chef scripts and found the soloistrc file to not be intention revealing. I bang-head-here a few times trying to make heads-or-tails out of it and some chef recipes. I wish some usability-testing had been done for it. Debugging can be painfully slow and it is not obvious how to reduce the feedback cycle when one thing breaks.

Good luck and I look forward to seeing what happens here

@spilth
Copy link
Contributor

spilth commented Jan 26, 2016

So why do people fork sprout-wrap, fix their problems there and never back porting them to the original project?

@spilth spilth closed this as completed in ccc04c7 Jan 26, 2016
@spilth
Copy link
Contributor

spilth commented Jan 26, 2016

Closing this by updating the README but feel free to continue the conversation.

@hiremaga
Copy link

First, let me say this project looks awesome! Thanks for taking the time to put it together @Splith.

Let me also try to answer your most recent question about sprout-wrap and its forks–sprout-wrap is intended to be a working example of how a team might compose the recipes and cookbooks, a starter project of sorts. Another approach, had we taken the time to implement this, might've been to have a command like rails e.g. sprout new that generates a soloistrc & Cheffile to get people started.

Your other feedback looks very valuable, thanks for sharing it here. If you'd like to see this incorporated into improving Sprout, I second @LukeWinikates's suggestion to also share it with the Sprout community. And, I'd encourage the others on the thread to do the same.

A little context–@wendorf kindly took over the responsibility of chaperoning Sprout from me a few months ago. Sprout (and pivotal_workstation before it) was built and is maintained by several Pivots and our friends with lots of love and very little spare time, we'd welcome more of both.

You can engage our community in a few ways:

  • Create issues & pull requests on the sprout-wrap repo or one of the other pivotal-sprout repos
  • Join & email sprout-users@googlegroups.com
  • Join the #sprout channel on Pivotal's Slack org (pivots only)

If you think Sprout's history might help inform this project–I'd be happy to share some of what we've learned since Sprout first came into existence as pivotal_workstation in 2009. Please don't hesitate to get in touch.

@spilth
Copy link
Contributor

spilth commented Jan 27, 2016

Your sprout new command sounds similar to an idea that @mikfreedman has of creating something like Spring Initializr for sprout-wrap projects.

We had a small meeting yesterday to talk about NYC provisioning and I've put together some notes that we plan to share with the sprout-wrap community.

I think one of the main issues is that people end up having to deal with sprout-wrap when they are starting up a project and by the time they sort out all their issues they are very eager to just get started on the actual project at hand instead of worrying about spending any more time fixing things in sprout-wrap.

@nertzy
Copy link
Contributor

nertzy commented Jan 27, 2016

Here's a link to the sprout-users google group for the lazy: https://groups.google.com/forum/#!forum/sprout-users

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants