shards install

[sdogruyol]

Much like go install github.com/x/y or cargo install --git 'github.com/x/y'

I think this eases the workflow of cloning the project, manually building and then exporting to path.

What do you think?

[ysbaddaden]

I'm not a fan of this. I prefer to have a shard.yml with a lock that's always the source (like Bundler) than "manually" fiddling with the libs folder.

[asterite]

Not a fan either. The dependency should be present in a committed file so the build is reproducible.

[sdogruyol]

How about the new cargo installin Rust? They also have cargo.toml for reproducible builds just like bundler.

More at rust-lang/rfcs#1200

[f]

Something like shards install --git sdogruyol/kemal@master would update the shard.yml file to make the installation easier. And so it will still have a shard.yml with a lock file which won't change anything but we have an installation helper.

[marceloboeira]

@f I like this approach, but I would suggest something less verbose, just:

shards install $user/$repo@${$tag, branch, commit}

[spalladino]

Sounds similar to what npm does when the --save flag is specified, and I can't remember a time when I did not use it.

[tommoor]

Hey! So I've just been intro'd to the Crystal language last week and I thought that this functionality needed to exist too so I started taking a stab at adding it in 😄 You can see my progress here (master...tommoor:feature/install-shard), right now the shard installs with the following syntax:

shards install user/repo@version

I'd like to have the command update the shard.yml npm style but I can't decide on the best approach for that - any thoughts?

[ysbaddaden]

Thanks for spending time on this, and dissecting shards internals!

Write shard.yml

This is a problem: Bower and NPM always reformat the JSON file. I hate that a script changes my formatting or reorders my file as it pleases. Outputting YAML is also trickier than JSON.

Supporting resolvers

Shards isn't GitHub centric and doesn't have to be Git centric at all. user/repo can refer to GitHub, GitLab or Bitbucket or anything else. We'd then need resolver:user/repo and have as many methods in the install command, but it shouldn't have to know anything about resolvers. Maybe delegate to each resolver? but resolvers are already complex enough. And what about the base Git resolver?

I don't think such a tiny helper for adding a dependency every once in a while is worth all that complexity.

[ysbaddaden]

To be completely honest: I never use this feature in any package manager and usually think it's more harmful than useful, and creates unrequited complexity.

This is my sole opinion on this. If I used this feature I would happily implement and maintain it. The problem is that I don't, and I don't want to support and maintain this feature...

[tommoor]

I hope you won't let your personal usage patterns get in the way of a potentially useful feature for the rest of the community... 😄

I'm absolutely happy to build it in such a way that resolvers are supported without adding complexity to the resolver classes themselves and it won't rearrange your yml file (although personally, I don't think that the yml file contents should be in the same order in every project!).

A couple of good reasons to include this that I can see:

• Pretty much every other package manager has this, it's expected functionality by newcomers and this aligns strongly with Crystals goal of being easy to use (even in this thread there is a lot of support).
• It makes installation instructions simpler and verbally communicable (Just look at pretty much any npm module's README)
• It takes something manual and makes it scriptable (which hacker doesn't love that?)

I won't work on this any further until you let me know either way.

[asterite]

Just to be sure, is this about installing binary executables to be available in the PATH, or just to install a library in the libs directory?

[tommoor]

@asterite this is following on from the last three comments before mine. It's about installing a shard with a command that will automatically update the shard.yml the same as npm install blah --save

[asterite]

I see. I agree more with @ysbaddaden, mostly because installing a shard is just copy/paste from the shard's instructions. It's also hard to do because we'd need to parse the yaml, modify it, and output it again, preserving comments and structure. I think this is very hard to do. And then there's the resolvers problem.

But if someone manages to implement this correctly, I don't think it's harmful. It's just that it will also involve a copy paste, only to the terminal instead of to a text file.

[tommoor]

That's disappointing, I think it's important that the project include these affordances and improve the quality of the tooling if you want to appeal to folks like JavaScript and Ruby developers.