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.
> 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.
> 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.
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.