[Nix-dev] monitor.nixos.org

Profpatsch mail at profpatsch.de
Tue Nov 29 16:05:30 CET 2016


On 16-11-28 11:05pm, Rok Garbas wrote:
> On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch <mail at 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.


More information about the nix-dev mailing list