3 ms·

For what it's worth I completely agree with you. I've recently started learning Rust and the only thing that truly bothers me about it is that it appears as tho

by cyphar 10y ago

For what it's worth I completely agree with you. I've recently started learning Rust and the only thing that truly bothers me about it is that it appears as though you _must_ use Cargo to manage your dependencies. I work for a company that supports a distribution (SUSE) and I also participate in a distribution's community (openSUSE) and this mentality of "let's just reinvent package management" really does bother me, because it feels like the benefits of having a single package manager for the entire system is being ignored. And this ease of pushing new packages results in a huge amount of small packages so that a standard "hello world" in many frameworks requires something like 700 packages (from a distribution side, that's 700 downstream packages that we now need to curate and maintain). Don't get me wrong, language package managers do have benefits, but they make life absolute hell for distributions. And distributions having full control of package management definitely brings benefits to users. Rust is the most extreme example, where projects can require a particular version of the nightly build of the compiler. How the hell is a distribution meant to be able to build and ship Rust code in that instance (given that distributions also provide the development tools necessary for working on said projects)? Do we create a new package for every nightly compiler build? How do we curate it? One of my colleagues gave quite a fair review of the situation and some potential future steps in his talk "Package Managers all the way down"[1]. But bringing this mentality verbatim to C++ is not a step in the right direction IMO. [1]: https://www.youtube.com/watch?v=4ua5aeKKDzU https://www.youtube.com/watch?v=4ua5aeKKDzU

steveklabnik 10y ago
You don't have to, it's just the path of least resistance. We've been working with distros on packaging stuff; it's mostly sorted. Each distro is doing the thing that works for them. Additionally, making sure we play well with other build systems is a big goal this year generally.
- nonsince 10y ago
  Also, for cargo's usecase (mostly-reproducable builds, a space that rubygems also attempts to fill) system package managers are simply insufficient. Nix is the only one that comes close, and you A) can't remotely expect anyone to have that installed already B) have no control over the repository or toolchain
- cyphar 10y ago
  > We've been working with distros on packaging stuff; it's mostly sorted. Each distro is doing the thing that works for them. Have you worked with openSUSE, since as far as I know devel:languages:rust is still in the state of "we aren't sure how to deal with these problems". In particular, there aren't any rust rpm macros in openSUSE yet, so there doesn't appear to be a clear way to create an rpm for a particular Rust project. I've written several things in Rust that I would love to package for our distribution, but I just don't know how we are meant to do it without depending on a network connection to download dependencies out-of-band (outside of rpms dependency system). > Additionally, making sure we play well with other build systems is a big goal this year generally. Yeah, that's the big problem at the moment. OBS provides huge benefits (rebuilds when dependencies change, tracking of security bugs and fixes) but it also has reasonable restrictions like not being able to connect to the internet. Having a better story in this respect _really would_ help Rust in its adoption in distributions.
  - steveklabnik 10y ago
    OpenSuse is a bit behind, say, Debian, but I thought there were people actively working on it. Las I remember, Rust and Cargo were packaged, but they weren't sure if they wanted to follow in Debian's footsteps and automatically convert packages or do something more manual like Arch. As long as ou have the stuff previously downloaded somewhere, offline builds of everything are totally supported; they're required not only by distros but by Firefox, for example.

by cyphar 10y ago

steveklabnik 10y ago

You don't have to, it's just the path of least resistance. We've been working with distros on packaging stuff; it's mostly sorted. Each distro is doing the thing that works for them. Additionally, making sure we play well with other build systems is a big goal this year generally.

nonsince 10y ago
Also, for cargo's usecase (mostly-reproducable builds, a space that rubygems also attempts to fill) system package managers are simply insufficient. Nix is the only one that comes close, and you A) can't remotely expect anyone to have that installed already B) have no control over the repository or toolchain
cyphar 10y ago
> We've been working with distros on packaging stuff; it's mostly sorted. Each distro is doing the thing that works for them. Have you worked with openSUSE, since as far as I know devel:languages:rust is still in the state of "we aren't sure how to deal with these problems". In particular, there aren't any rust rpm macros in openSUSE yet, so there doesn't appear to be a clear way to create an rpm for a particular Rust project. I've written several things in Rust that I would love to package for our distribution, but I just don't know how we are meant to do it without depending on a network connection to download dependencies out-of-band (outside of rpms dependency system). > Additionally, making sure we play well with other build systems is a big goal this year generally. Yeah, that's the big problem at the moment. OBS provides huge benefits (rebuilds when dependencies change, tracking of security bugs and fixes) but it also has reasonable restrictions like not being able to connect to the internet. Having a better story in this respect _really would_ help Rust in its adoption in distributions.
- steveklabnik 10y ago
  OpenSuse is a bit behind, say, Debian, but I thought there were people actively working on it. Las I remember, Rust and Cargo were packaged, but they weren't sure if they wanted to follow in Debian's footsteps and automatically convert packages or do something more manual like Arch. As long as ou have the stuff previously downloaded somewhere, offline builds of everything are totally supported; they're required not only by distros but by Firefox, for example.