To Neal's point, I had the audacity to suggest some improvements along the lines of docutils and the response was underwhelming. https://users.rust-lang.org/t/rust-analog-to-the-python-compilers-docutils/82813?u=blaisep
On Thu, Oct 20, 2022 at 10:02 AM Neal Gompa <ngomp...@gmail.com> wrote: > On Thu, Oct 20, 2022 at 9:39 AM Kevin Kofler via devel > <devel@lists.fedoraproject.org> wrote: > > > > Matthew Miller wrote: > > > I fundamentally disagree with Kevin on a deep level about "entirely > > > useless", but ... find myself kind of agreeing about the "unpackagable" > > > part. I mean: clearly we've found a way, but I'm really not sure we're > > > providing a lot of _value_ in this approach, and I'm also not sure > it's as > > > successful as it could be. > > > > We cannot ship what we cannot package. (Just repackaging upstream blobs > is a > > no-go, it is explicitly banned by Fedora Packaging Guidelines for good > > reasons.) > > > > > I'll start with the second: our system for Rust doesn't really do that. > > > Developers are going to use cargo and crates.io and we're not going to > > > convince them that they should do otherwise. (I don't expect anyone > > > disagrees with this.) > > > > That is one of the issues (along with lack of proper shared library > support) > > that makes Rust such a painful language: it makes it way too easy for > > developers to just add a dependency on some random unpackaged (by > > distributions) library with some random license and with random > transitive > > dependencies. > > > > In a reasonable programming language, you have to think twice before you > add > > yet another dependency to your project. Tools like cargo make it way too > > easy, just add a line and rebuild. So then you end up with a mess like > this: > > > > > But running `cargo fetch` with a clean cache pulls down *390* crates. > > > > 390 dependencies is absolutely insane! No project should ever depend on > so > > many libraries. This is completely unmaintainable. > > > > > *This is what open source winning looks like.* > > > > > > I remember a Byte magazine article from the 1990 (I just checked!) with > > > the title "There Is a Silver Bullet: The birth of interchangeable, > > > reusable software components will bring software into the information > > > age". [1] This was about the newly-hot idea of Object Oriented > > > Programming. It was very exciting. But, of course, that vision of the > > > world did not happen. It turns out proprietary software *can't* do > this. > > > > > > But now we have it! I don't have to reinvent every basic wheel — but > even > > > more than that, I do not have to be an expert in the intricacies of > safe > > > concurrency to write an app that uses that under the hood. That's > amazing! > > > I can do such powerful things from high-level interfaces and trust the > > > expertise of those who really understand the deep computer science > some of > > > this requires. > > > > Code reuse is great when it makes sense, but this "NPM culture" where > > developers happily depend on tons of packages containing trivial one-line > > functions is completely insane. > > > > If this is now the essence of "Open Source", then it will ultimately > lose. > > Proprietary software companies will just be waiting for the next paradigm > > shift to lock us into their proprietary ecosystem again. For a large > part, > > this has already happened with smartphones: you get to choose only > between > > the Android walled garden (with an open core and lots of proprietary > Google > > services and (Google and third-party) apps on top) and the iOS walled > garden > > (which is completely proprietary and closed, even strictly enforcing an > App > > Store monopoly). We are struggling to escape from that with devices like > the > > PinePhone. But with development practices relying on an unmaintainable > > dependency hell, it will never happen. > > > > > I am competent enough to write a silly toy game using Bevy. It might be > > > good enough that others will enjoy it. *I am not competent to maintain > > > many of these dependencies.* I don't even know what most of them DO. > > > "anyhow"? "bytemuck"? > > > > Welcome to dependency hell! > > > > > Worse, many of the Bevy deps are specified with exact versions. Maybe I > > > could make the package work with the packaged versions, but ... that > > > requires deep expertise and even then might lead to unexpected behavior > > > and has a high chance of putting me at odds with both the engine > upstream > > > and any other games which use it. The packaging guidelines say that I > > > SHOULD create patches to update to latest versions of dependencies, and > > > that I should further convince the upstream to take them. Candidly, > that > > > seems like a waste of everone's time. > > > > Hardcoding exact versions of dependencies is one of the worst > misfeatures of > > those language-specific build tools. It effectively prevents you from > fixing > > security issues without patching every single application. And of course > it > > can cause version conflicts between different applications or even > between > > transitive dependencies within an application. (And, while the former > ones > > can typically be resolved by shipping both versions of the library, the > > latter ones cannot, because you cannot usually link two versions of the > same > > library into the same program.) > > > > > So, going back to Kevin's point: it _does_ feel like this is > unpackagable. > > > But that's because the barrier to participation seems too high. > > > > No, the answer to upstream shipping an unpackageable mess cannot > possibly be > > to make it easier to smuggle unpackageable messes into Fedora! > > > > > It's not because it's statically-linked binaries [2] can't or shouldn't > > > exist in Fedora — that's not one of our core principles! > > > > It is actually one of our Packaging Guidelines that static linking is > > discouraged: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries > > as is bundling libraries: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > > > > (So they can indeed exist, but they definitely SHOULD NOT, the Guidelines > > undisputably say so.) > > > > > In fact and quite to the contrary, we need to adapt to handle this > amazing > > > open source success story better. > > > > I fail to see a success story here. I see a failure story. Dependency > hell > > is not a success. > > > > > And, I led with: I appreciate all the work you've all done to make this > > > work. That's definitely true — I think it was super-valuable to pilot > this > > > approach. But I think that the Rust ecosystem would be a great place to > > > pilot a different way. Something lightweight where we cache crates and > use > > > them _directly_ in the build process for _application_ RPMs. > > > > Fabio has already explained very well why that is a horrible idea. > > > > > Fedora _needs_ to adapt to stay relevant in the world where every > language > > > stack has developed a packaging ecosystem which effectively ignores us. > > > Some of them are missing lessons they could have learned, ah well — but > > > they also have a lot of nice new ideas we're missing. And, no matter > what > > > we think, we're clearly not going to stop them. > > > > Rust needs to adapt to become relevant in GNU/Linux distributions. > > > > There is nobody pushing for Rust to improve anymore. When Igor and I > were building out Fedora Rust, we did some engagement with Rust > upstream about stabilizing Rust's ABI so we could ship dynamic > libraries. While one or two members of the Rust core team were > sympathetic, most of the Rust community attacked me for "trying to > make Rust like C" and I got crap from people on the Rust community > channels, Twitter, and other places. Eventually, I flamed out because > there's only so much punishment someone can take over it. > > A couple of years ago, there was a revival of the topic[1], but it > went nowhere again. > > Until the situation changes, I'm very firmly anti-Rust. Unfortunately, > sometimes I have no choice but to deal with it. > > [1]: https://github.com/slightknack/rust-abi-wiki > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora <https://www.quora.com/profile/Blaise-Pabon> | Github <https://github.com/blaisep> “If you want to go fast, go alone. If you want to go far, go together.” --African proverb
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
