[Nix-dev] monitor.nixos.org

[zimbatm]

Yeah but I'm still wondering how that would work in the context of nixpkgs.

Are we always updating to the latest version? For example on a release
branch we might want to pin to a major.minor if the project follows semver,
but maybe on master we always want the latest version.

How do we iterate over all the packages? Do we regularly run all the update
scripts? Are the updates directly pushed to master or are new PR
automatically created?

Let's say the convention is that derivations exposes an "updater" passthru.
Does it mean that all the derivations need to be updated or can we
magically support all github projects?

I still think that some of this need to be tried out so we might as well
adopt garbas' approach for now but it would be nice to have a clearer
picture as well.

On Thu, 1 Dec 2016, 03:13 Tomasz Czyż, <tomasz.czyz at gmail.com> wrote:

> zimbatm: I don't think you need that branch selection thing. All the
> custom logic you want for that package you can put in the update script and
> you can even parametrize it from the outside I assume (update script
> generated by nix expression). That should be enough to do whatever custom
> logic you want.
>
> 2016-11-29 15:05 GMT+00:00 Profpatsch <mail at profpatsch.de>:
>
> 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.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
>
> --
> Tomasz Czyż
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20161201/2b46dbf9/attachment-0001.html>