Include `shards` binary with official build about omnibus-crystal HOT 13 OPEN

Sure!

Yesterday we were discussing with @waj how to do this. For example, the homebrew formula. We'd like to have crystal optionally depend on shards, but to install shards you'll need crystal, hmmm...

So @waj came up with this: there's a crystal-compiler formula that doesn't depend on any other formula. Then there's shards, which depends on crystal-compiler. And then we have crystal-lang, a "meta" formula/package, that depends on crystal-compiler and shards.

So, omnibus won't need to change. For other systems (like Ubuntu) the same could be done, but @waj told me that those systems allow circular dependencies because they are just binaries, so it could be simpler.

What do you think?

/cc @jhass @ysbaddaden

from omnibus-crystal.

That also means that shards will depend on libyaml, but not crystal-compiler, at least now.

from omnibus-crystal.

That doesn't sound like anything you would ever get into the main hombrew repo. At Arch we simply patched the crystal deps error message to say "please do pacman -S shards" and made crystal optionally depend on shards and since it's a binary package distribution crystal is merely a buildtime dependency of shards.

I think that tiny extra step of brew install shards isn't too bad until we want to distribute shards in same package/distribution and lock step their releases.

from omnibus-crystal.

So, omnibus won't need to change. For other systems (like Ubuntu) the same could be done, but @waj told me that those systems allow circular dependencies because they are just binaries, so it could be simpler.

That will require also shards be distributed as deb package, which isn't right now.

I thought similar to building Crystal, Shards can be built and distributed along the same deb package.

from omnibus-crystal.

Yes, that could also work pretty well. But then the homebrew forumla crystal-lang will automatically include shards, right?

from omnibus-crystal.

@luislavena not yet: crystal-lang/shards#59

Linux packages won't have problems depending on each other, as long as they are binaries. Installing one will install the other as a dependency.

I second @jhass: it's not that cumbersome to run <pkg> install shards and have crystal shards display a platform dependent message about how to install it when the binary can't be found.

from omnibus-crystal.

I can only imagine a user downloading a project that has dependencies, doing crystal deps, getting an error and thinking "WT* were they thinking? If dependencies are something crucial, why doesn't it come in the crystal binary/package itself?". It's not about how simple it is to install shards later, it's about the user experience and the frustration that it might cause.

My vote has always been to include shards inside the compiler. All these discussions would vanish and everything would work out of the box. But it seems I'm the only one thinking this :-(

from omnibus-crystal.

Small note: I'm not angry (I never am in these discussions), I was just imagining an angry user saying/thinking that.

from omnibus-crystal.

@ysbaddaden thank you for the response. I believe shards will not depend on Crystal itself (since is already a binary) but only on libyaml for runtime execution.

However, while I do understand the reasoning for making both separate packages, first-time user experience is not very good.

I know, I know, you would argue that we are pre-1.0 so quirks are acceptable and then people forget and assume the quirk is the default and the bump on the learning curve and UX is there, because everybody got used to it, except the new user.

I think shards can exists in it's own repository and when packaging Crystal, we can pick the latest stable release (from releases tab) of Shards and build it, that way, new Crystal releases ships with latest Shards.

If Shards gets updated independently, then have the separate Shards packages or binaries for the user to download.

Take for example Rust and Cargo, Cargo is distributed as part of Rust and Rust Nightly, but you can download Cargo separately from nightly builds too, so both release cycles are not totally bound to each other (like Ruby and RubyGems, for example).

Thank you.

from omnibus-crystal.

The point is that you actually can't do that, the shards package would conflict with the crystal package.

from omnibus-crystal.

@luislavena Shards packages should depend on Crystal because it makes little sense to have Shards installing dependencies if you don't have the compiler to build the project.

@asterite You're right, installing a Crystal package should install Shards along. That would simplify user experience, CI configuration, and be more pleasant. I'm just wondering about manually compiled packages from tarballs, but I guess it makes you a contributor / power user / package manager, and I guess you can install shards yourself? You're likely to have been reading installation instructions.

@jhass we can have the shards binary in different places. For instance the bundled one can be /opt/crystal/bin/shards whereas the shards package would be /usr/bin/shards. Crystal would append /opt/crystal/bin (actually File.dirname(File.realpath(PROGRAM_NAME))) to $PATH so a binary is usually always found when running crystal shards, but leaving preference to any other one (installed manually, throught a package, or whatever) and eventually failing with a message if it really can't be found.

from omnibus-crystal.

Considering binary conflicts when files are coming from different packages, why not:

• Package Shards as crystal-shards binary with the Crystal default package (use latest release)
• Make crystal deps or crystal shards to look for shards executable if present, and not, default to packaged crystal-shards

This will allow two things: avoid the conflict of same binary provided by different packages and workaround the broken please install this other thing experience.

You can always include instructions to update/install Shards to a newer version independently of the one packaged with Crystal and that will not conflict.

Sounds reasonable?

Thank you.

from omnibus-crystal.

I agree here with @asterite . shards should be included not just delivered with the compiler IMO. Exposing shards in the way it was exposed in 0.8 might had added some additional noise but it I see it as an intermediate step.

In the future, if there are scenarios that would require by an update only in shards it might be worth to deliver a new minor version of language. Otherwise when including libraries with dependencies we would need to not only check crystal-version but shard-version (in case we add those checks in the future).

Dependencies are too important to the language, so I like to see them as a single entity.

from omnibus-crystal.