3 ms·

It was discussed for Meson when they included the "subproject" support as major issue for all the GNOME components for most linux distributions. There is some

by adev_ 8y ago

It was discussed for Meson when they included the "subproject" support as major issue for all the GNOME components for most linux distributions. There is some note here https://mesonbuild.com/Subprojects.html https://mesonbuild.com/Subprojects.html or here https://blogs.gnome.org/ignatenko/2015/05/21/meson-and-3rd-party-dependencies-only-one-correct-way/ https://blogs.gnome.org/ignatenko/2015/05/21/meson-and-3rd-p... Or more recently with Bazel that do the same but arrives to do it much worst: https://github.com/tensorflow/tensorflow/issues/6210 https://github.com/tensorflow/tensorflow/issues/6210 or https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ https://archive.fosdem.org/2018/schedule/event/how_to_make_p... Same with Hunter and CMake External: https://github.com/ruslo/hunter/issues/296 https://github.com/ruslo/hunter/issues/296 I have managed an ecosystem of ~250 software for a team in the past. Software bundling their dependencies are the worst and any package manager will tell you that. Due to diamond dependency problem, they explode as soon as you try to integrate them into a bigger picture... It is a pure waste of time for every packager. And I am not even speaking of bug fixes update on dependencies, security update, environment without Internet access or anything like that.... because dependency bundling prevent or make hard all of that.

ajmmertens 8y ago
"How to make a package manager cry" - lol. In all seriousness, the links you provided outline valid (and annoying) issues with package managers, but none of them apply to bake. First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're good. You'll never lose productivity because your internet connection went down (well- at least not because of bake). Secondly, the bake package manager does not mandate how you install your projects. This is perhaps the point of greatest confusion. Bake is a package manager for developers, and it provides a nice & seamless workflow for integrating remote git dependencies into your local workflow. How you package and distribute your projects is entirely up to you. Also, bake has been used to support an ecosystem of 150+ projects, across multiple teams, across multiple organizations, on multiple platforms before it was forked off. In these cases, organizations used their own preferred tools for deployment, but got a good productivity boost from using bake in development.
- adev_ 8y ago
  > First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're good. You'll never lose productivity because your internet connection went down (well- at least not because of bake). It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. > Bake is a package manager for developers, and it provides a nice & seamless workflow for integrating remote git dependencies into your local workflow Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it.
  - ajmmertens 8y ago
    > It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. As you put so eloquently before, that should not be the prerogative of build systems like bake, but of package managers like apt-get, brew and vcpkg. Bake is blissfully agnostic to those problems (thank god). One thing that hasn't been discussed so far and I would like to highlight is code that is not distributed through package managers, as so often is the case for commercial closed source code. Bake is a great fit for these use cases, as these projects can simply zip up the bake environment (together with miscellaneous files like HTML, JS and what have you), unzip it on a different machine, and everything just "magically" works. > Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it. If you got the impression that I am on a quest to convert every non-bake project to bake, then let me put that concern to rest. I love using bake, it is saving me lots of time and, TBH, I think there are some neat ideas in bake that other people might like, but that's it. After the code is built, it's like every other C/C++ library, and people are free to use whatever build system they feel comfortable with to link with those libraries.

by adev_ 8y ago

ajmmertens 8y ago

"How to make a package manager cry" - lol. In all seriousness, the links you provided outline valid (and annoying) issues with package managers, but none of them apply to bake. First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're good. You'll never lose productivity because your internet connection went down (well- at least not because of bake). Secondly, the bake package manager does not mandate how you install your projects. This is perhaps the point of greatest confusion. Bake is a package manager for developers, and it provides a nice & seamless workflow for integrating remote git dependencies into your local workflow. How you package and distribute your projects is entirely up to you. Also, bake has been used to support an ecosystem of 150+ projects, across multiple teams, across multiple organizations, on multiple platforms before it was forked off. In these cases, organizations used their own preferred tools for deployment, but got a good productivity boost from using bake in development.

adev_ 8y ago
> First of all, bake does not rely on an online package repository. As long as you have access to git, or have local copies of your git repositories, you're good. You'll never lose productivity because your internet connection went down (well- at least not because of bake). It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. > Bake is a package manager for developers, and it provides a nice & seamless workflow for integrating remote git dependencies into your local workflow Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it.
- ajmmertens 8y ago
  > It does not change anything to all the other problems of bundling dependencies. Including the problems related to diamond dependencies. As you put so eloquently before, that should not be the prerogative of build systems like bake, but of package managers like apt-get, brew and vcpkg. Bake is blissfully agnostic to those problems (thank god). One thing that hasn't been discussed so far and I would like to highlight is code that is not distributed through package managers, as so often is the case for commercial closed source code. Bake is a great fit for these use cases, as these projects can simply zip up the bake environment (together with miscellaneous files like HTML, JS and what have you), unzip it on a different machine, and everything just "magically" works. > Then just use a developper package manager like Nix, Guix, Spack or EasyBuild that do the staff. Instead of converting every other project to Bake for the sake of it. If you got the impression that I am on a quest to convert every non-bake project to bake, then let me put that concern to rest. I love using bake, it is saving me lots of time and, TBH, I think there are some neat ideas in bake that other people might like, but that's it. After the code is built, it's like every other C/C++ library, and people are free to use whatever build system they feel comfortable with to link with those libraries.