Git Product home page Git Product logo

Comments (4)

roberth avatar roberth commented on July 18, 2024 2

I believe it is feasible once we've narrowed down the interfaces. I wouldn't exclude the possibility that a truly different project wants to use it, although I am not aware of an example. I could see Lix or Tvix use it though. I haven't been in touch with them about this yet, but I believe the concept of reproducible fetching has a better chance of success when there's a serious project that has this as its single purpose. Specifically, it allows for more collaboration, and it is the cheapest way to have consensus about what any fetchable source should evaluate to. The alternative, competing implementations that converge on a standard, takes much more effort, and neither team seems particularly excited to work on fetchers, from what I can tell.
Without a suitable standard implementation, the only remaining choices for them are to either: give up on the concept of lazy reproducible fetching, or work on an alternate implementation that diverges (such as stabilizing the buggy 2.18 implementation in an incompatible way).

from nix.

Ericson2314 avatar Ericson2314 commented on July 18, 2024 1

I would say

  1. Meson build
  2. Use Meson subproject to build each library in own derivation
  3. Move fetchTree primop and libfetchers -> libexpr to additional library (primops can be registered downstream in plugin fashion)

Step 4 would be making that additional library work as plugin, but we'll have to untangle some CLI stuff.

Future work could be be ABI stability and actually moving things out of tree, but I don't feel so urgent about that.

I do think having the core SourceAccessor stuff remaining in libutil and be used by libexpr is good, however.

from nix.

fricklerhandwerk avatar fricklerhandwerk commented on July 18, 2024

Yes, whether something is in the tree doesn't matter, it's all about strong boundaries in interfaces and ownership. Namespaces merely help with delineating responsibilities.

Side note: shouldn't libutil become a library for file system handling then?

from nix.

edolstra avatar edolstra commented on July 18, 2024

The use case for this is unclear to me. What other project would use libfetchers? It's extremely Nix-specific. Meanwhile it would make hacking on Nix much more painful.

from nix.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.