Live data from Hacker News

Cargo, Rust's Package Manager

crates.io

91–100 of 127 posts

Re: Cargo, Rust's Package Manager

#91
post #74

Earlier quoted context omitted.

I think it would be just as easy to package rust programs using OS native package management as anything else, and I'm sure packages will be made for popular things for common package managers. But OS native package managers are a royal pain to use when actively developing on a project that has some dependencies, and bespoke Makefiles are a very imperfect solution. Flipping your question around a bit: will package ma…

This is an insightful point. Nix is the only package manager I'm aware of that seems like it could fit the bill: https://nixos.org/nix/

Yeah, nix does look pretty awesome and aware of (even actively designed for )both the system administration and development use cases. If it becomes the native package manager for some popular operating systems, I may have to eat my words about language-specific solutions.

Re: Cargo, Rust's Package Manager

#92
post #87

What about binary only dependencies?

I think mixed is also very important. For example, sometimes you really do only have a binary dependency (e.g., .NET assemblies), while other times, you may have a binary + source dependency (e.g., library + header files).

Re: Cargo, Rust's Package Manager

#94
post #93

Learn two things: 1. Wycats (Yehuda Katz) is on Rust apparently :) 2. `.toml` -- some crossbreed YAML/INI file format that I like

It'd be really nice if it didn't impose a hard choice of json-ish to use for the manifest, even though that's a rather small thing. Just don't want to be stuck with toml if it doesn't gain wider acceptance than it has so far.

Re: Cargo, Rust's Package Manager

#95
post #4

Earlier quoted context omitted.

I may not be a majority here, but I see JSON as a data transportation format, while I see TOML or YAML as configuration formats. You cannot write comments in JSON, for instance.

YAML is a serialization format, not a configuration format.

It's really a configuration format that mistook itself for a serialization format.

What I wouldn't do for a cut-down YAML standard with most of the serialization crap cut out.

Re: Cargo, Rust's Package Manager

#96
While I support semantic versioning, people need to be aware that it's only as good as the package maintainer. I have used packages that have (unintentionally) broke semver conformity. Nothing really stops an author from releasing breaking changes when going from "1.2.1" to "1.2.2".

Re: Cargo, Rust's Package Manager

#97

This is sweet: For example, if I have three packages: - uno depends on json 1.3.6 - dos depends on json 1.4.12 - tres depends on json 2.1.0 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. Hopefully rust builds a culture that respects semantic versioning better than the Ruby & Node cultures do. That has to start at the top. There were several Rails 2.3.X releases with minor ABI incompatibilities.…

Npm require modules to follow semver. https://www.npmjs.org/doc/package.json.html#version

Now sure why you think the culture there doesn't respect semver.

Re: Cargo, Rust's Package Manager

#98

Earlier quoted context omitted.

I don't know about the security vulnerabilities, but it works fine as a config file format (we use it at my company for a lot of in-house stuff). I had a similar reaction to the language. Even if not YAML, why not just use JSON? It's universal, dead simple to use and understand, has extensive libraries in just about any language, etc... That said it's not that big of a deal. At least it's not an in-house markup like…

> I don't know about the security vulnerabilities, About 14 months ago, it caused some of the most serious vulnerabilities in the Ruby on Rails world ever: http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html > why not just use JSON? JSON is not really human-editable. Those quotes and commas, ugh! Also, JSON lacks comments. The vulnerabilities in YAML (which is a superset of JSON, by the way) point at why YAML and…

> About 14 months ago, it caused some of the most serious vulnerabilities in the Ruby on Rails world ever: http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html

Live by eval, die by eval. But more seriously, nobody is forcing a Rust YAML library to support arbitrary structure deserialization (or maybe as an optional switch). I don't think you'd want such a switch on in a build system configuration file.

Re: Cargo, Rust's Package Manager

#99

Earlier quoted context omitted.

That's a fairly weak argument. If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0. Otherwise you're opening yourself up to the exact same issue you outline as an issue for Bundler -- people assumping a pre-1.0 project is stable. As long as there's the option for someone to say "this is pre 1.0 so I can change it whenever" it's going to cause concern because most of us have b…

> If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0. Absolutely. Let me make an issue about that: https://github.com/rust-lang/cargo/issues/46 If he doesn't respond, I will email him. > As for the FUDdiness... Thanks! Since the points are enumerated, I can refute them: > * You can't override a dependency: You can, in modern Bundlers. But the transitive dependency issue is i…

I would like to take the opportunity to say that your fast, no-bullshit answers (and actions) are appreciated (in general the Rust community seems to foster this sort of positive attitude, carry on).

Re: Cargo, Rust's Package Manager

#100

Earlier quoted context omitted.

> I don't know about the security vulnerabilities, About 14 months ago, it caused some of the most serious vulnerabilities in the Ruby on Rails world ever: http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html > why not just use JSON? JSON is not really human-editable. Those quotes and commas, ugh! Also, JSON lacks comments. The vulnerabilities in YAML (which is a superset of JSON, by the way) point at why YAML and…

> About 14 months ago, it caused some of the most serious vulnerabilities in the Ruby on Rails world ever: http://tenderlovemaking.com/2013/02/06/yaml-f7u12.html Live by eval, die by eval. But more seriously, nobody is forcing a Rust YAML library to support arbitrary structure deserialization (or maybe as an optional switch). I don't think you'd want such a switch on in a build system configuration file.

Then you're not supporting YAML, you're supporting your own subset of YAML.
Post reply on HN