GNU bug report logs -
#71700
The Archiving functionality of guix lint should be opt-in and Documented more prominently
Previous Next
To reply to this bug, email your comments to 71700 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#71700
; Package
guix
.
(Fri, 21 Jun 2024 18:13:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
MSavoritias <email <at> msavoritias.me>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Fri, 21 Jun 2024 18:13:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hey,
There was recently a discussion around SWH and it came up that `guix lint` actually by default when you run it without arguments, runs all the linters.
One of them being the archive linter that contacts SWH archive to let it know where to download the source code from (if its a public repo).
I would like to propose to make that linter off by default. Because:
The tool is name `guix lint` and it is not obvious (unless somebody runs --list-linters after --help) that it also does code archiving.
To that end it breaks the expectations of the person using the tool to have their code silently uploaded to SWH. (if its a public repo again)
What we should do instead:
Instead we should document more prominently in the manual that `guix lint` also does archiving and encourage people to actually archive the software they write to SWH.
(assuming they are the authors that is. A disclaimer to get permission from the author of the software should be also added if they are not.)
And for the usecase of Guix, they flag can just be turned on by default since as a project we are interested in code archival.
MSavoritias
Information forwarded
to
bug-guix <at> gnu.org
:
bug#71700
; Package
guix
.
(Fri, 21 Jun 2024 18:49:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 71700 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Fri, 21 Jun 2024 at 19:45, MSavoritias <email <at> msavoritias.me> wrote:
> I would like to propose to make that linter off by default.
Somehow I disagree with this. And I propose the generic approach that
allows to exclude any checkers from the package definition using the
field properties.
See <https://issues.guix.gnu.org/71697#1>.
Cheers,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#71700
; Package
guix
.
(Sat, 22 Jun 2024 13:22:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 71700 <at> debbugs.gnu.org (full text, mbox):
I think channel level configuration of some form for code archival is a
good idea so individual channels can choose to disable it. I also agree
that we should make the fact that guix lint does archival more
prominent.
I disagree with a statement that permission is required, but I'll avoid
rehashing the discussion ongoing in guix-devel. [1]
I think there is a good reason to support disabling archival at the
channel level. Simon, do you think your patch can/will manage that?
> Somehow I disagree with this. And I propose the generic approach that
> allows to exclude any checkers from the package definition using the
> field properties.
>
> See <https://issues.guix.gnu.org/71697#1>.
[1]: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00192.html
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#71700
; Package
guix
.
(Sat, 22 Jun 2024 14:25:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 71700 <at> debbugs.gnu.org (full text, mbox):
On Sat, 22 Jun 2024 09:21:01 -0400
Richard Sent <richard <at> freakingpenguin.com> wrote:
> I think channel level configuration of some form for code archival is a
> good idea so individual channels can choose to disable it. I also agree
> that we should make the fact that guix lint does archival more
> prominent.
>
> I disagree with a statement that permission is required, but I'll avoid
> rehashing the discussion ongoing in guix-devel. [1]
>
> I think there is a good reason to support disabling archival at the
> channel level. Simon, do you think your patch can/will manage that?
That is still missing the usage of people wanting to run `guix lint` without having a channel.
A channel level mechanism would be nice indeed but we still need a way to account for the archiving functionality for people who dont have channels or dont run channels.
The proposal of making it explicitely enabled would work as a solution for that use case.
That way the channel configuration would be to enable it instead of disabling it. opt-in/opt-out and all that.
It also avoids the mistake of not realizing it exists or is enabled and accidentally somebodys code ends up in SWH without them meaning too.
Not everybody reads the manual after all and we shouldnt do stuff we havent been explicitly required to do.
In short I would say a channel level mechanism would help to "automate" the opt-in of running `--archival` everywhere with `guix lint`.
MSavoritias
> > Somehow I disagree with this. And I propose the generic approach that
> > allows to exclude any checkers from the package definition using the
> > field properties.
> >
> > See <https://issues.guix.gnu.org/71697#1>.
>
> [1]: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00192.html
>
Information forwarded
to
bug-guix <at> gnu.org
:
bug#71700
; Package
guix
.
(Sat, 22 Jun 2024 16:24:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 71700 <at> debbugs.gnu.org (full text, mbox):
Hi Richard,
On Sat, 22 Jun 2024 at 09:21, Richard Sent <richard <at> freakingpenguin.com> wrote:
> I think there is a good reason to support disabling archival at the
> channel level. Simon, do you think your patch can/will manage that?
Yeah it could be helpful. However, my patch does not address at this
level.
I agree it could be an other complementary direction. But the design at
channel needs to be thought a bit, IMHO.
Cheers,
simon
This bug report was last modified 77 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.