proposal: with-file-writeable

proposal: with-file-writeable

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

the make-file-writeable function seems a bit too imperative to me, it would
look better if we could have a with-file-writeable function, so that we can
constrain the size effect, and more. Moreover if a file is read-only to
start with, it might be a good idea to keep it that way anyways. WDYT?

[-- Attachment #2: Type: text/html, Size: 317 bytes --]

Re: proposal: with-file-writeable

[Ludovic Courtès]

Gábor Boskovits <boskovits@gmail.com> skribis:

> the make-file-writeable function seems a bit too imperative to me, it would
> look better if we could have a with-file-writeable function, so that we can
> constrain the size effect, and more. Moreover if a file is read-only to
> start with, it might be a good idea to keep it that way anyways. WDYT?

Which ‘make-file-writeable’ function?  I don’t see it in master.

Ludo’.

Re: proposal: with-file-writeable

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Wed, Feb 14, 2018 at 02:51:08PM +0100, Ludovic Courtès wrote:
> Gábor Boskovits <boskovits@gmail.com> skribis:
> 
> > the make-file-writeable function seems a bit too imperative to me, it would
> > look better if we could have a with-file-writeable function, so that we can
> > constrain the size effect, and more. Moreover if a file is read-only to
> > start with, it might be a good idea to keep it that way anyways. WDYT?
> 
> Which ‘make-file-writeable’ function?  I don’t see it in master.

There was a typo; it's ((guix build utils) make-file-writable)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: proposal: with-file-writeable

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

2018-02-14 20:13 GMT+01:00 Leo Famulari <leo@famulari.name>:

> On Wed, Feb 14, 2018 at 02:51:08PM +0100, Ludovic Courtès wrote:
> > Gábor Boskovits <boskovits@gmail.com> skribis:
> >
> > > the make-file-writeable function seems a bit too imperative to me, it
> would
> > > look better if we could have a with-file-writeable function, so that
> we can
> > > constrain the size effect, and more. Moreover if a file is read-only to
> > > start with, it might be a good idea to keep it that way anyways. WDYT?
> >
> > Which ‘make-file-writeable’ function?  I don’t see it in master.
>
> There was a typo; it's ((guix build utils) make-file-writable)
>

Sorry, yes, my mistake, it's really  ((guix build utils)
make-file-writable).

[-- Attachment #2: Type: text/html, Size: 2094 bytes --]

Re: proposal: with-file-writeable

[Ludovic Courtès]

Gábor Boskovits <boskovits@gmail.com> skribis:

> the make-file-writeable function seems a bit too imperative to me, it would
> look better if we could have a with-file-writeable function, so that we can
> constrain the size effect, and more. Moreover if a file is read-only to
> start with, it might be a good idea to keep it that way anyways. WDYT?

Now that I found the function in (guix build utils) (thanks for guiding
me!), I see what you mean.  ‘make-file-writable’ is imperative, true,
but I’d say that file system operations are imperative in nature.

A ‘with-file-writeable’ form would give a false sense of “containment” I
think.  Contrary to what the name suggests, its effect would *not* be
limited to the dynamic extent of its body, in the current thread;
instead, the effect would be globally visible on the system.

Last, the style of (guix build utils) is a lesser concern in a way
because its primary use case is package builds.  All this code is
“plumbing” and mostly imperative.

So, all in all, I’d rather keep it this way.

Thoughts?

Ludo’.

Re: proposal: with-file-writeable

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

2018-02-15 0:28 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:

> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > the make-file-writeable function seems a bit too imperative to me, it
> would
> > look better if we could have a with-file-writeable function, so that we
> can
> > constrain the size effect, and more. Moreover if a file is read-only to
> > start with, it might be a good idea to keep it that way anyways. WDYT?
>
> Now that I found the function in (guix build utils) (thanks for guiding
> me!), I see what you mean.  ‘make-file-writable’ is imperative, true,
> but I’d say that file system operations are imperative in nature.
>
> A ‘with-file-writeable’ form would give a false sense of “containment” I
> think.  Contrary to what the name suggests, its effect would *not* be
> limited to the dynamic extent of its body, in the current thread;
> instead, the effect would be globally visible on the system.
>
> Last, the style of (guix build utils) is a lesser concern in a way
> because its primary use case is package builds.  All this code is
> “plumbing” and mostly imperative.
>
> So, all in all, I’d rather keep it this way.
>
> Thoughts?
>
>
Ok, the keep it this way. Another question, this came up, as
I was trying to find a nice solution to reset-gzip-timestamps failing.
I got different pieces of advice if I should reset the permissions after
resetting the timestamp, but I'm still not sure. It seems that the easiest
way to this would be to just add a call to make-file-writable to the phase
at the beginning, as we finally end up with a read-only one in the store
anyway. I feel that reseting the permissions is unneccesary additional
complexity. WDYT?


> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 2396 bytes --]

Re: proposal: with-file-writeable

[Ludovic Courtès]

Gábor Boskovits <boskovits@gmail.com> skribis:

> Ok, the keep it this way. Another question, this came up, as
> I was trying to find a nice solution to reset-gzip-timestamps failing.
> I got different pieces of advice if I should reset the permissions after
> resetting the timestamp, but I'm still not sure. It seems that the easiest
> way to this would be to just add a call to make-file-writable to the phase
> at the beginning, as we finally end up with a read-only one in the store
> anyway. I feel that reseting the permissions is unneccesary additional
> complexity. WDYT?

I don’t know, is this (read-only permission on installed files) a common
problem?

As you can see I’m fairly conservative when it comes to changing (guix
build utils).  :-)

The reason for this is that changing it entails full rebuilds.  Thus,
the approach so far is to try to make the procedures in there fairly
generic (with keyword/optional parameters, etc.) so that they are
applicable to a wide range of use cases.  At the same time, we try to
make changes there only when we’d have to repeat ourselves in package
recipes.  If a problem shows up in just one package, we adjust the
package definition and leave (guix build utils) unchanged.

Ludo’.

Re: proposal: with-file-writeable

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

2018-02-15 14:22 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:

> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > Ok, the keep it this way. Another question, this came up, as
> > I was trying to find a nice solution to reset-gzip-timestamps failing.
> > I got different pieces of advice if I should reset the permissions after
> > resetting the timestamp, but I'm still not sure. It seems that the
> easiest
> > way to this would be to just add a call to make-file-writable to the
> phase
> > at the beginning, as we finally end up with a read-only one in the store
> > anyway. I feel that reseting the permissions is unneccesary additional
> > complexity. WDYT?
>
> I don’t know, is this (read-only permission on installed files) a common
> problem?
>
> As you can see I’m fairly conservative when it comes to changing (guix
> build utils).  :-)
>
> The reason for this is that changing it entails full rebuilds.  Thus,
> the approach so far is to try to make the procedures in there fairly
> generic (with keyword/optional parameters, etc.) so that they are
> applicable to a wide range of use cases.  At the same time, we try to
> make changes there only when we’d have to repeat ourselves in package
> recipes.  If a problem shows up in just one package, we adjust the
> package definition and leave (guix build utils) unchanged.
>
>
I've seen this mostly with packages coming from git checkout in the python
world.
I've seen at least two packages in the last three month. It is mostly test
data.
It actually seems to be common there, but usually it is not a problem when
we
can use pypi. I don't know how common it is in other areas.

I also don't know if we have any other phase where these kind of permission
problems can lead to errors, but it would be nice, if we could check that,
and
fix all of them with one commit. It should be based on core-updates, of
course,
and not in this round, I guess.

Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 2643 bytes --]

Re: proposal: with-file-writeable

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

Gábor Boskovits <boskovits@gmail.com> writes:

> Ok, the keep it this way. Another question, this came up, as
> I was trying to find a nice solution to reset-gzip-timestamps failing.
> I got different pieces of advice if I should reset the permissions after
> resetting the timestamp, but I'm still not sure. It seems that the easiest
> way to this would be to just add a call to make-file-writable to the phase
> at the beginning, as we finally end up with a read-only one in the store
> anyway. I feel that reseting the permissions is unneccesary additional
> complexity. WDYT?

In the "strip" phase we already call "make-file-writeable"
unconditionally, so doing it in reset-gzip-permissions as well should be
okay I think.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: proposal: with-file-writeable

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

2018-02-15 15:16 GMT+01:00 Marius Bakke <mbakke@fastmail.com>:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
> > Ok, the keep it this way. Another question, this came up, as
> > I was trying to find a nice solution to reset-gzip-timestamps failing.
> > I got different pieces of advice if I should reset the permissions after
> > resetting the timestamp, but I'm still not sure. It seems that the
> easiest
> > way to this would be to just add a call to make-file-writable to the
> phase
> > at the beginning, as we finally end up with a read-only one in the store
> > anyway. I feel that reseting the permissions is unneccesary additional
> > complexity. WDYT?
>
> In the "strip" phase we already call "make-file-writeable"
> unconditionally, so doing it in reset-gzip-permissions as well should be
> okay I think.
>

Ok, thanks, I will prepare a patch.

[-- Attachment #2: Type: text/html, Size: 1372 bytes --]

Re: proposal: with-file-writeable

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Gábor Boskovits <boskovits@gmail.com> writes:
>
>> Ok, the keep it this way. Another question, this came up, as
>> I was trying to find a nice solution to reset-gzip-timestamps failing.
>> I got different pieces of advice if I should reset the permissions after
>> resetting the timestamp, but I'm still not sure. It seems that the easiest
>> way to this would be to just add a call to make-file-writable to the phase
>> at the beginning, as we finally end up with a read-only one in the store
>> anyway. I feel that reseting the permissions is unneccesary additional
>> complexity. WDYT?
>
> In the "strip" phase we already call "make-file-writeable"
> unconditionally, so doing it in reset-gzip-permissions as well should be
> okay I think.

Right, especially if this affects a number of packages already.

Ludo’.