Crystal tagged builds now available - should they replace nightlies?

[oprypin]

https://github.com/crystal-lang/crystal/releases/tag/1.3.1 https://github.com/crystal-lang/crystal/releases/download/1.3.1/crystal-1.3.1-windows-x86_64-msvc-unsupported.zip

I think these downloads should become what 'crystal.json' is about. Whereas the current 'crystal.json' might be moved to 'crystal-nightly'.

These downloads also contain 'shards.exe'. Perhaps 'shards.json' could rely on that exact same download but keep only 'shards.exe' from it. Or do you think 'crystal.json' should provide 'shards.exe'? (I don't think so)

Ref https://github.com/crystal-lang/crystal/issues/11489#issuecomment-978200203

[neatorobito]

Agreed, I will update the main crystal.json to serve the tagged builds and then move our current solution to crystal-nightly.

As far as bundling shards, there was some discussion about it in #14. I made some changes since at first I was onboard with leaving them separate, but when I dug deeper and installed crystal on Linux the other day I noticed that it came with shards out of the box.

Can you install the crystal binary by itself from a package manager on Linux or is it always bundled with shards?

If it's always bundled, seems like it would make much more sense to just bundle them on Windows as well so we can provide the same experience everywhere. And it would be easier that way since we moved it to the nightly zip.

[straight-shoota]

Can you install the crystal binary by itself from a package manager on Linux or is it always bundled with shards?

Yes. All native package managers typically do that. For example, Arch package repository, BSD ports, Aports. That's the proper way to do this. Only the packages distributed by Crystal directly usually ship shards and crystal in a single package. That's just for simplicity because we tried to avoid extra effort for multiple packaging systems. I'd like to change that eventually, though. It's definitely better to have separate packages.

[neatorobito]

It's definitely better to have separate packages.

What's the rationale behind this? I think this issue you responded to on the forum highlighted why we would want a bundled package instead. Package managers provide convenience among other things, so it makes sense to provide Crystal with batteries included. If someone only needs the crystal binary they can grab it from GitHub.

Only the packages distributed by Crystal directly usually ship shards and crystal in a single package.

This is another discussion I wanted to start up. Scoop would be a great way to provide (preview and stable) packages on Windows officially going forward. I'd like to ultimately see this repository under official Crystal org or Crystal community org jurisdiction. How do you both feel about that?

[straight-shoota]

so it makes sense to provide Crystal with batteries included.

Definitely. But that's not a contradiction. You can have separate packages but install them together.

The benefit of separate packages is that they're no longer tied to each other and you can for example install a newer version of shards than whatever would be bundled with the latest crystal release. They can advance at different speeds.

Having the scoop repo managed by the community sounds like a good idea. I'm not sure about whether we'd want to take it as an official repository in crystal-lang. That's a question of how much we want to get involved with package management. In general, I think I'd prefer to leave most of it to downstream maintainers in order to move responsibility away from the core project.

[neatorobito]

I'm still not convinced of the need for separation on Windows specifically right now. Bundling is also more pragmatic since there's now a shards binary just hanging out in the zip file. It's also consistent since most package managers bundle shards and even most of the releases direct from the GitHub Releases page bundle shards. If they don't need shards they can grab the zip from the releases page and pick the pieces they need.

Basically, I'd argue y'all made the correct choice in the first place. It provides a great developer experience, it's less work on the core crystal development team as you pointed out, and people using newer languages are used to having a dependency manager bundled.

Python ships pip by default, Rust ships cargo by default, C# ships nuget by default, etc.

Having the scoop repo managed by the community sounds like a good idea. I'm not sure about whether we'd want to take it as an official repository in crystal-lang. That's a question of how much we want to get involved with package management. In general, I think I'd prefer to leave most of it to downstream maintainers in order to move responsibility away from the core project.

Sounds good to me. I'll open an issue to maybe move it over here.

Edit: I did not mean to close this, I forgot to uncheck close when merging the linked PR.

[straight-shoota]

Python ships pip by default, Rust ships cargo by default, C# ships nuget by default, etc.

That's completely true and I wouldn't want anything else for Crystal. But those dependency manager usually still ship as separate packages in most package managers (see https://repology.org/project/python:pip/versions, https://repology.org/project/cargo/versions, https://repology.org/project/nuget/versions). And that makes very much sense, alone by the fact that these tools typically have their own release management.

[oprypin]

Python ships pip by default

By the way, Debian packagers rip that out of Python and split it up into a separate package anyway :D

[neatorobito]

Python ships pip by default, Rust ships cargo by default, C# ships nuget by default, etc.

That's completely true and I wouldn't want anything else for Crystal. But those dependency manager usually still ship as separate packages in most package managers (see https://repology.org/project/python:pip/versions, https://repology.org/project/cargo/versions, https://repology.org/project/nuget/versions). And that makes very much sense, alone by the fact that these tools typically have their own release management.

Okay, looks like it's possible to have the best of both worlds. I added it back as a separate package.

Since I merged the other PR it's now bundled by default, but you can do the same scoop install shards and it'll just override the bundled one.

[neatorobito]

See comments in closed PR.