5 ms·

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also started working on an initiative to improve Nix documentation which was spread all over the places. [1] https://bob.build/ https://bob.build/

biggestlou 4y ago
Bob is very cool and I think that there's room for lots of tools like this that build _on_ Nix but abstract away some of the trickier parts. Suggestion: make Bob installable with Nix!
- zuzuleinen 4y ago
  Thanks for the suggestion! It makes sense to have it on Nixpkgs collection since anyway you need to install Nix alongside bob Already created an issue :) https://github.com/benchkram/bob/issues/193 https://github.com/benchkram/bob/issues/193
yewenjie 4y ago
How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.
- zuzuleinen 4y ago
  I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. Are you referring here to packages which are not available in Nixpkgs? [1] https://bob.build/docs/usage/package-management https://bob.build/docs/usage/package-management
  - rgoulter 4y ago
    The point is: a couple of the tough points in packaging something with Nix are "how to come up with the Nix expression", but also how to get the software you're packaging to build with the constraints Nix has (no fetching external dependencies, shared libraries explicitly declared in non-standard locations, etc.). A bespoke YAML format is arguably not simpler than just "here's the equivalent Nix expression". But, sure, can be more accessible for some people. But, providing a nice facade over the Nix language doesn't help with cases of where Nix can be difficult to work with.
    - zuzuleinen 4y ago
      > But, providing a nice facade over the Nix language doesn't help with cases of where Nix can be difficult to work with. This is true. If you reach the point where you need to write your own Nix expression you currently can become stuck. But I think these are problems that are waiting to be solved. There are folks are already working on a new language tutorial at nix.dev for example and other tools that can abstract some of the problems we have now can be built. I believe we are still in an early stage when it come to reproducibility and we just have to keep working at it.
- ParetoOptimal 4y ago
  > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. The basic way to fix this with nix is: 1) download the thing with a fixed ouput derivation: a derivation who's source has the URL and checksum of the artifact 2) copy the artifact from the nix store where said build tool stores it
  - rgoulter 4y ago
    In nix expressions, sure; but bob uses YAML, and uses that to drive nix.
    - deleted 4y ago
      [deleted]
    - zuzuleinen 4y ago
      Yes, basically you can list your packages in the yaml file and have them installed. But you can also add .nix expression files in the same bob.yaml that can be used to build your packages when a package is not found on Nixpkgs.
emptysongglass 4y ago
Is Bob complementary to Devbox recently featured in a Show HN here and would you be willing to explain how you might use both together if so?
- zuzuleinen 4y ago
  I think they only way in which they are similar is the way a user would add dependencies for a project. If with devbox a user populates devbox.json with package names, with bob you add dependencies in list inside bob.yaml. You can find out more in a short guide[0] I wrote. But bob intends to be more than a dependency manager, it wants to be fully-fledged build system similar to Dagger, Bazel, Earthly etc with features like: * build pipelines[1]. You can define and manage your build pipelines in a familiar YAML format. You also get caching for your targets and so on. * isolated environment. We completely clear the environment for a task. I see with devbox that if I do a `printenv` or an `echo PATH` while I'm still in an active devbox shell, I see variables from my local system which can affect reproducibility. * workspaces: manage multi-repo setups in an easy manner [0] https://bob.build/docs/usage/package-management https://bob.build/docs/usage/package-management [1] https://bob.build/docs/usage/build https://bob.build/docs/usage/build

biggestlou 4y ago

Bob is very cool and I think that there's room for lots of tools like this that build _on_ Nix but abstract away some of the trickier parts. Suggestion: make Bob installable with Nix!

zuzuleinen 4y ago
Thanks for the suggestion! It makes sense to have it on Nixpkgs collection since anyway you need to install Nix alongside bob Already created an issue :) https://github.com/benchkram/bob/issues/193 https://github.com/benchkram/bob/issues/193

yewenjie 4y ago

How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.

zuzuleinen 4y ago
I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. Are you referring here to packages which are not available in Nixpkgs? [1] https://bob.build/docs/usage/package-management https://bob.build/docs/usage/package-management
- rgoulter 4y ago
  The point is: a couple of the tough points in packaging something with Nix are "how to come up with the Nix expression", but also how to get the software you're packaging to build with the constraints Nix has (no fetching external dependencies, shared libraries explicitly declared in non-standard locations, etc.). A bespoke YAML format is arguably not simpler than just "here's the equivalent Nix expression". But, sure, can be more accessible for some people. But, providing a nice facade over the Nix language doesn't help with cases of where Nix can be difficult to work with.
  - zuzuleinen 4y ago
    > But, providing a nice facade over the Nix language doesn't help with cases of where Nix can be difficult to work with. This is true. If you reach the point where you need to write your own Nix expression you currently can become stuck. But I think these are problems that are waiting to be solved. There are folks are already working on a new language tutorial at nix.dev for example and other tools that can abstract some of the problems we have now can be built. I believe we are still in an early stage when it come to reproducibility and we just have to keep working at it.
ParetoOptimal 4y ago
> Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. The basic way to fix this with nix is: 1) download the thing with a fixed ouput derivation: a derivation who's source has the URL and checksum of the artifact 2) copy the artifact from the nix store where said build tool stores it
- rgoulter 4y ago
  In nix expressions, sure; but bob uses YAML, and uses that to drive nix.
  - deleted 4y ago
    [deleted]
  - zuzuleinen 4y ago
    Yes, basically you can list your packages in the yaml file and have them installed. But you can also add .nix expression files in the same bob.yaml that can be used to build your packages when a package is not found on Nixpkgs.

emptysongglass 4y ago

Is Bob complementary to Devbox recently featured in a Show HN here and would you be willing to explain how you might use both together if so?

zuzuleinen 4y ago
I think they only way in which they are similar is the way a user would add dependencies for a project. If with devbox a user populates devbox.json with package names, with bob you add dependencies in list inside bob.yaml. You can find out more in a short guide[0] I wrote. But bob intends to be more than a dependency manager, it wants to be fully-fledged build system similar to Dagger, Bazel, Earthly etc with features like: * build pipelines[1]. You can define and manage your build pipelines in a familiar YAML format. You also get caching for your targets and so on. * isolated environment. We completely clear the environment for a task. I see with devbox that if I do a `printenv` or an `echo PATH` while I'm still in an active devbox shell, I see variables from my local system which can affect reproducibility. * workspaces: manage multi-repo setups in an easy manner [0] https://bob.build/docs/usage/package-management https://bob.build/docs/usage/package-management [1] https://bob.build/docs/usage/build https://bob.build/docs/usage/build