Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Monday January 26 2015, @02:36PM   Printer-friendly
from the declaration-of-dependance dept.

When Daniel Pfeifer gave a talk about dependency management in 'When dependency hell freezes over' at Meeting C++ last year, he said: "Try to complete the following sentence: Python has Pip, Ruby has Gem, Dart has Pub, C++ has... "

Unfortunately, we cannot continue the sentence because there is no solution for resolving and keeping track of dependencies and version compatibilities for C/C++ projects. This is where biicode is trying to fill the gap.

And even though it started as a closed source project it looks like it is going to become open source.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by WillR on Monday January 26 2015, @02:45PM

    by WillR (2012) on Monday January 26 2015, @02:45PM (#138177)
    ...your platform's package manager.

    Which is what Python, Ruby, Perl, etc. should be using as well.
    • (Score: 1, Interesting) by Anonymous Coward on Monday January 26 2015, @03:33PM

      by Anonymous Coward on Monday January 26 2015, @03:33PM (#138185)

      Yes, because all platform package managers support multiple versions of one package extremely well. Also, I always have root rights on all machines I'm using, and I love to install things system wide for all users! It has never been a source of problems or conflicts!

      • (Score: 0) by Anonymous Coward on Monday January 26 2015, @03:54PM

        by Anonymous Coward on Monday January 26 2015, @03:54PM (#138192)

        ...and once again DLLs are superior.

        • (Score: 2) by tibman on Monday January 26 2015, @05:50PM

          by tibman (134) Subscriber Badge on Monday January 26 2015, @05:50PM (#138249)

          Because dlls have version numbers on them, right? Common DLLs are terrible and that is why most products ship with their own version/copy. So you end up with duplicate DLLs on the same system. Instead of shipping your product with a dependency on a 3rd party library you just ship the third party library right with your executables.

          --
          SN won't survive on lurkers alone. Write comments.
          • (Score: 1) by gnuman on Monday January 26 2015, @08:59PM

            by gnuman (5013) on Monday January 26 2015, @08:59PM (#138314)

            Either SxS or install DLLs in your application folder. Both existed since Windows 2000. There is really no excuse to shipping unversioned DLL and sticking it in a windows directory.

          • (Score: 2) by TheRaven on Tuesday January 27 2015, @09:55AM

            by TheRaven (270) on Tuesday January 27 2015, @09:55AM (#138488) Journal

            Common DLLs are terrible

            Common DLLs come with your OS, you only need to ship the uncommon ones. Unless you actually meant 'come on'.

            Because dlls have version numbers on them, right?

            On *NIX systems .so files all have a version number right there in the file name. You often can't link two versions of the same library though, because of symbol conflicts (it is possible on OS X because the run-time linker supports a two-level namespace, but it's still not a very good idea). The real problem is that most libraries are not just a library, they are a set of resources as well and the different versions of the resources still have the same file names even when the libraries have different ones.

            --
            sudo mod me up
            • (Score: 2) by tibman on Tuesday January 27 2015, @02:55PM

              by tibman (134) Subscriber Badge on Tuesday January 27 2015, @02:55PM (#138558)

              The DLLs thing was a jab at windows complete lack of dependency management. In linux, even the uncommon libraries are not shipped with the program. The program has a set of dependencies that it expresses to the package manager. It's up to the package manager to handle those dependencies. This allows security patching of 3rd party libraries. In windows you buy/download a program that is bundled with 3rd party libraries. Those libraries will not be updated unless the host program does it. You could even have several instances of the same DLL packaged with different programs. Each with their own unique update procedure.

              --
              SN won't survive on lurkers alone. Write comments.
    • (Score: 2) by darkfeline on Monday January 26 2015, @03:44PM

      by darkfeline (1030) on Monday January 26 2015, @03:44PM (#138190) Homepage

      I think I agree with you, but having a package manager built in to the language makes packaging easier on distros.

      --
      Join the SDF Public Access UNIX System today!
      • (Score: 3, Informative) by forsythe on Monday January 26 2015, @08:27PM

        by forsythe (831) on Monday January 26 2015, @08:27PM (#138302)

        having a package manager built in to the language makes packaging easier on distros

        As a former package maintainer for a hobbyist distro: No, it doesn't. When you get a report from a user saying ``$FOO doesn't work'', and $FOO is a huge spider with dependency chains numbering in the hundreds, and the problem turns out to be that the user had installed library 3.x in $LANG locally, which was overriding the system's library 3.(x+1), your job is NOT made easier.

        And now, to segue a bit...

        It also really doesn't help when the hobbyist operating system you're helping maintain has some oddly-strict POSIX-isms that not all software follows, which means that you actually have to perform, you know, maintenance. Of course the library-specific repo isn't run by people who focus on POSIX-correctness, they just ensure that $FOO runs on Fedora, Ubuntu, and (if you're lucky) vanilla Debian. So as a user of HobbyistOS, you're now in a situation where the language package manager mostly works, but sometimes installs broken garbage.

        Can we talk about code quality now? How about I just link here [gentooexperimental.org] and here [nist.gov] and be done with it. Package managers are tricky things that are often run as root and which can easily screw up your system. Why would you want to increase their attack/failure surface? (And if your package manager can't install system-wide, why would I want to install a separate copy of a library for every user who wants it?)

        Now let's talk about stability, security, etc. of the packages themselves. I'm pretty confident that the folks running my distro's repositories have vetted their packages (At least, I tried to be pretty thorough when I was a maintainer). They've volunteered their time for the purpose of making sure the packages are correct. In many cases, they patch stuff up when it isn't. Language package managers generally don't do that. In some cases - e.g. Go's [google.com], there is absolutely no vetting at all: it's all links to other repos, and if somebody feels like deleting their repository (or worse, pushing a commit that replaces the library with ``exec("rm -rf /*")'' ), there's nothing you can do except search around for a backup of the library (or of your system).

        Now finally, let me talk about this from a development standpoint: I hate this because it contributes to a culture that makes it that much harder to write code that works between/with multiple languages. How is my Ruby package manager supposed to know that my Python package manager just updated its side of the system, and that some Ruby package needs to upgrade in response? What if that Ruby package now depends on a different version of a package written in Perl? What if that new Rust thingy gets into the picture? That's n-squared complexity, and what's being measured is the number of ties between completely different development teams with orthogonal or directly opposing goals, and all of them are fighting over your system. The obvious answer is ``They don't do that''. So good luck having a Python package that depends on something outside of Python*. The result is that every language community lives in its own little world, rarely talking to each other, all reinventing the same wheels side by side.

        *Oh yes, they exist. And they're as ugly and hacky and broken. I learned that the hard way tracking down seemingly impossible memory corruption errors in a Python library that depended on libqd, and did so by secretly building its own, outdated, buggy libqd, then squirreling it away and ignoring my system's updated, patched libqd.

        Please don't build any more language-specific package managers. I have a very nice package manager installed already, and there's a very good team of people behind it. Put the effort you were going to put into $PACKAGE_MANAGER into making your libraries easy to configure and package, please.

        • (Score: 1) by dmbasso on Tuesday January 27 2015, @12:05AM

          by dmbasso (3237) on Tuesday January 27 2015, @12:05AM (#138362)

          I have a very nice package manager installed already,

          ... that works for your specific flavour of Linux. I understand your PoV as a maintainer, but if you look from the PoV of a programmer, making it easy for contributors to start coding is priceless. Nothing beats the `pip install -r requirements.txt` (or the equivalent in the other frameworks), which works on Linux, Windows, OSX, etc.

          And then, when you decide to make packages for the various Linux distros yourself, you find out that every single one of them have a f**ing different package name for your dependencies... e.g, in one it will be `python-markdown`, the other `markdown`, another `Markdown`, argh!!!

          --
          `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    • (Score: 3, Informative) by Thexalon on Monday January 26 2015, @05:34PM

      by Thexalon (636) on Monday January 26 2015, @05:34PM (#138243)

      For commonly installed system-wide packages, Python/Ruby/Perl etc indeed can make use of the standard package manager. If you check, you'll find packages named things like "python-openid" in your package manager.

      Where pip/gems/cpan come in is when you're installing a specific library for a specific project, possibly in a development environment. That makes it really easy to build installation scripts that work equally well on, say, Debian-based Linux and BSD.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    • (Score: 2) by umafuckitt on Tuesday January 27 2015, @07:58AM

      by umafuckitt (20) on Tuesday January 27 2015, @07:58AM (#138467)

      From a user perspective, this is absolutely true when it works and when the package manager has all the packages you need. Python development on Linux thus us pretty easy. It's more of a pain on a Mac, say, where the more unusual packages can be harder find and/or harder to compile and the package managers are less awesome.

  • (Score: 4, Informative) by Gravis on Monday January 26 2015, @03:38PM

    by Gravis (4596) on Monday January 26 2015, @03:38PM (#138187)

    as i read "C / C++ dependency manager with a cloud-based service," i realized the issue, it's a service. so i looked at the TOS and what do i see?

    ...
    previously registered users store computer source code either for free (hereinafter known as the “FREE” category), or by payment of a fee (hereinafter referred to as the “PREMIUM” category)
    ...

    this is an advertisement for a problem claiming to be a solution. really, is it that hard to use pkg-config? works great on *nix platforms. though if you are on windows, you already have a second problem.

    • (Score: 5, Informative) by ticho on Monday January 26 2015, @03:43PM

      by ticho (89) on Monday January 26 2015, @03:43PM (#138189) Homepage Journal

      I agree, this seems to me like an attempt to create a fruity hipster new-age brogrammer community for C/C++, much like there are ones for RoR or javascript. The mere fact that their website does not display *anything* with javascript enabled clearly shows who their target audience is. :)

      • (Score: 1) by ticho on Monday January 26 2015, @03:45PM

        by ticho (89) on Monday January 26 2015, @03:45PM (#138191) Homepage Journal
        Eh, that should have been "with javascript disabled"
    • (Score: 0) by Anonymous Coward on Tuesday January 27 2015, @01:02PM

      by Anonymous Coward on Tuesday January 27 2015, @01:02PM (#138519)

      Somebody at MS wanted to sell their pet project, a package manager extension for Visual Studio; Herb Sutter was then told to sell everyone the delusion that "C++ needs an apt-get tool urgently; come download NuGet, it's cross platform! *" every C++ conference he goes to. Those are the moments when Herb loses all his credibility.

      Frankly, all the non-MS world needs is a script like "debuginfo-install" (which is common in RPM-based distros); call it "pkg-lib-install", and print out the command-line you need to install the missing packages.

      * It works on all MS-supported platforms.