6 ms·

How is it different than depending on e.g. Python?

• rjsw 7y ago
  Python doesn't currently require a working Python binary to build itself. Both Bazel and Java do.
  • new_realist 7y ago
    A C compiler, which Python needs, is arguably as complex as either a Python or Java runtime.
    • jcranmer 7y ago
      A C compiler is a functional requirement of any operating system these days.
      • pjmlp 7y ago
        You won't go very far with it on Android, ChromeOS, iOS, iPadOS, mbed, Arduino, console OSes,...
        • creatornator 7y ago
          The Arduino IDE calls out to avr-gcc, and mbed-os is written in c++ so requires an embedded c++ compiler like arm-gcc or something similar. ChromeOS also runs the Linux kernel so you do need it to compile the OS, and it can hypothetically run binaries compiled for the linux platform. Dig deep enough through all the layers of bootstrapping and you'll find c basically everywhere.
          • pjmlp 7y ago
            GCC is written in C++. ChromeOS users don't compile their kernel. Crostini is built with Rust and Go.
    • hannob 7y ago
      This is an irrelevant statement. You need the C compiler anyway. Your Java or Python is built with C. You add the complexity of your other environment on top of it.
• hannob 7y ago
  Ask any person that has ever tried to package a python and a java package for any linux distribution. The Python ecosystem is much, much simpler than Java.
  • lima 7y ago
    Is it, really? The Java ecosystem had painless build artifacts figured out way before Python did (ship this directory of .jar files vs... a requirements.txt?).
    • LukeShu 7y ago
      Java's build artifacts are too painless. GNU/Linux distributions tend to have a policy of "we build things from source, we don't simply re-publish the authors' build artifacts." Because Java's build artifacts are so painless, source artifacts and build processes are neglected. I'm convinced that there are many "foundational" Java libraries that have never been successfully compiled on anything but the original author's computer, right before they uploaded the .jar to Maven Central. With a Java package, the final distro package will mostly be a single .jar file under /usr/share/java/, but getting to that .jar file from source is often a nightmare. With a Python package, the final distro package will mostly be a sprawling directory under /usr/lib/python/site-packages/, but getting that directory from source is very rarely anything more than `./setup.py install --optimize=1`.
      • lima 7y ago
        Agreed about Maven Central. It's scary. In my experience, large, complicated Python packages with C dependencies can be a huge nightmare just like large Java applications, and simple cases are simple in either case. With many dependencies, you need to unbundle every single one and package it separately, in either case. Here's a simple, random Java package in Fedora: https://src.fedoraproject.org/rpms/maven-antrun-plugin/blob/master/f/maven-antrun-plugin.spec https://src.fedoraproject.org/rpms/maven-antrun-plugin/blob/... It only specifies its dependencies (which are individually packaged), and the %mvn_build and %mvn_install macros take care of everything else. A slightly more complicated one, Guava: https://src.fedoraproject.org/rpms/guava/blob/master/f/guava.spec https://src.fedoraproject.org/rpms/guava/blob/master/f/guava... Elasticsearch, including unbundling patches: https://src.fedoraproject.org/rpms/elasticsearch/blob/master/f/elasticsearch.spec https://src.fedoraproject.org/rpms/elasticsearch/blob/master...