On 16-11-28 11:05pm, Rok Garbas wrote: > On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch <m...@profpatsch.de> wrote: > > Exactly. > > And of course the interface of what the script at this point should do. > > We don't need to define what that update script should do, since a > maintainer of that package also makes sure that generated files > (json/nix/...) that this update script provides will be read by the > package expression.
In order for CI to check for updates there needs to be a standard way to call these update scripts. And more than that, a standard behaviour of these update scripts. I expect CI to completely sandbox them. Maybe even go so far as to loosen the “fixed input” rule only a tiny bit, meaning the update scripts have to specify exactly what state they are going to inspect to find new versions. > I think Nix has the advantage here actually. A maintainer can write an > update script in any language that he is most comfortable with. On the > end they have to support it etc... BUT everybody can run the update > without knowing that this is a ruby script since ``nix-shell`` > provides all the needed dependencies for us. As long as updates always behave the same. And don’t rm -rf your $HOME … I’ve had enough untrusted source code run for two lifetimes. > So on the end we really need to just figure out the name ;) and start > writing update scripts. Even if they are full of regex :P If there is no interface, I’d rather not even have a fix name, or people will think updates are specified somehow. Maybe even go the other way and reserve the name until someone figures out a nice way to do this. -- Proudly written in Mutt with Vim on NixOS. Q: Why is this email five sentences or less? A: http://five.sentenc.es May take up to five days to read your message. If it’s urgent, call me. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
