Re: [Spam:]Re: “What’s in a package”

[Konrad Hinsen <konrad.hinsen@cnrs.fr>]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> As we've seen these past years with COVID-19 and the world's supply
> chains, efficiency has some kind of inverse relationship with
> robustness. If you go too far down the path of efficiency, you are not
> very flexible, and you're building sand castles.

That's exactly what I have seen happening in scientific software for a
while :

  https://hal.archives-ouvertes.fr/hal-02117588

> It's for this reason I appreciate having "robust" software underneath
> my sand castle. At least I know only so much can crumble :)

100 % agreement!

> I want to be careful here in what I suggest. I think it is very
> important that Guix remain a bastion of robust software with very high
> standards. I don't want to see the PyPi PyTorch packages of the world

Me neither. My suggestion was for support in Guix the tool, not Guix the
software distribution. People can/should package their sand castles in
their private channels.

> So with your example: make it really easy to transform that PyPi
> package into a terrible Guix primitive of some kind, but don't let me
> commit it to Guix proper.

I trust our maintainer team to not let this happen.

> Maybe interactive software that introspects how a package
> is written and behaves at runtime (in a container?) and utilizes the
> homoiconicity of scheme to suggest modifications of the package, or
> next steps. E.g. expand the linter to suggest things like

That sounds interesting!

> Speaking of industry, I don't think we leverage software to build software enough.

Definitely not.

> And by the way, none of those ideas would be possible if Guix weren't
> such a robust and sane ecosystem.

Exactly. We can discuss (and more) adding sloppy stuff on top of Guix,
but it wouldn't work the other way round.


"Jonathan McHugh" <indieterminacy@libre.brussels> writes:

> Your focus regarding a transition from exploratory to robust is
> important (though may have equal significance in the other
> direction?).

Not equal as I see it, but yes, it matters as well, for dragging a
stable package out int the open again for significant improvements.

> Would security experts have (understandable) criteria to prioritise
> choices for 'robust corridors' within an ecosystem of sourcefiles and
> encapsulated blobs?

I'd love to hear from security experts too!

Konrad.