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

Add rake task to build release packages that bundle traveling ruby #19

Closed
wants to merge 8 commits into from

Conversation

JoelQ
Copy link
Collaborator

@JoelQ JoelQ commented Jan 6, 2015

Distributing command-line applications as Ruby gems is cumbersome. It requires users to reinstall the application every time they upgrade their Ruby version and it breaks on machines that run older versions of Ruby. It also makes installation more painful for non-Ruby devs.

A better approach is to use a package manager such as Homebrew. This PR creates a set of rake tasks to generate packages that can be tied to a release. It also bundles traveling ruby so as not to depend on the existing rubies on a user's system.

The packages contain shims for Parity's binaries which just run them using traveling ruby. The generated packages have the following structure:

parity-0.4.1-osx
├── bin # shims
│   ├── development
│   ├── production
│   └── staging
└── lib
    ├── app # parity app
    │   ├── README.md
    │   ├── bin
    │   └── lib
    └── ruby # traveling ruby

Packages can be generated with rubies for the following targets:

  • OSX rake package:osx
  • Linux x86 rake package:linux:x86
  • Linux x86_64 rake package:linux:x86_64

or for all packages rake package:all

These packages would then be attached to a release on github. They could be manually downloaded and extracted to a directory with /bin was in PATH or they could be installed via a package manager.

I created a working Homebrew formula that pulls this release on my fork as a proof of concept.

JoelQ added 8 commits January 5, 2015 14:18
The gem version needs to be referenced in multiple places so a `Parity::VERSION`
constant was extracted to hold this value.
* development
* staging
* production
Support for:

* x86
* x86_64
@JoelQ
Copy link
Collaborator Author

JoelQ commented Jan 14, 2015

@croaky Any thoughts on this change?

@croaky
Copy link
Contributor

croaky commented Jan 14, 2015

This looks like a great idea but I haven't had a chance to review it
closely yet or try it out. I hope to on Friday.

On Wed, Jan 14, 2015 at 8:34 AM, Joël Quenneville [email protected]
wrote:

@croaky https://github.com/croaky Any thoughts on this change?


Reply to this email directly or view it on GitHub
#19 (comment).

@croaky
Copy link
Contributor

croaky commented Mar 15, 2015

Awesome work, @JoelQ. Merged as 7916985. Sorry for the delay getting this in. Adding you and @geoffharcourt as committers in case you want to make other updates in the future.

@croaky croaky closed this Mar 15, 2015
@croaky
Copy link
Contributor

croaky commented Mar 15, 2015

@JoelQ Do you think there's a way to automatically create the Linux versions using Travis?

@geoffharcourt
Copy link
Collaborator

Nice!

@JoelQ
Copy link
Collaborator Author

JoelQ commented Mar 16, 2015

@croaky You mean to test OS-specific builds on Travis?

@croaky
Copy link
Contributor

croaky commented Mar 16, 2015

@JoelQ I mean to generate the tarball. Right now, the 0.5.0 release only has the OS X version but would be nice to offer the Linux version. Could ask a coworker like @jferris or someone to generate it but would be cool to automate it somehow. I was thinking maybe CI for that, or Docker?

@JoelQ
Copy link
Collaborator Author

JoelQ commented Mar 16, 2015

Ah, I see. The tarball doesn't have to be generated on the target system. That's the whole point of using traveling-ruby. You should be able to generate all the tarballs on you local machine and upload them to the github release page.

@croaky
Copy link
Contributor

croaky commented Mar 17, 2015

Ah, I see. The tarball doesn't have to be generated on the target system. That's the whole point of using traveling-ruby. You should be able to generate all the tarballs on you local machine and upload them to the github release page.

Whooaaa. Mind asplode.

@croaky
Copy link
Contributor

croaky commented Mar 18, 2015

Also adding @gabebw as a collaborator.

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

Successfully merging this pull request may close these issues.

3 participants