GNU bug report logs - #44130
[PATCH] Add a recursive version of mkdir-p

Previous Next

Package: guix-patches;

Reported by: divoplade <d <at> divoplade.fr>

Date: Wed, 21 Oct 2020 23:31:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44130 in the body.
You can then email your comments to 44130 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Wed, 21 Oct 2020 23:31:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to divoplade <d <at> divoplade.fr>:
New bug report received and forwarded. Copy sent to guix-patches <at> gnu.org. (Wed, 21 Oct 2020 23:31:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: divoplade <d <at> divoplade.fr>
To: guix-patches <at> gnu.org
Subject: [PATCH] Add a recursive version of mkdir-p
Date: Thu, 22 Oct 2020 01:29:48 +0200
[Message part 1 (text/plain, inline)]
Dear guix,

I need this mkdir-p function in any non-trivial program I write. I had
3 bad choices:

1. Lobby guile to provide this function out of the box (this will take
time);
2. Copy that of guix, or gash, or any other: this does not seem
acceptable to me, because this function will surely evolve (for
instance, if guile gets suport for mingw and we start running guile
programs on windows) and I don't want to update more than one version
of this function;
3. Depend on guix, gash or another package: this would be too large a
dependency for my programs.

So I wrote it in its own package and I intend to depend on it for my
other projects. It would be best if you could accept this package in
guix proper.

What do you think?

Best regards,

divoplade
[0001-Add-guile-mkdir-p.patch (text/x-patch, attachment)]

Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 13:13:02 GMT) Full text and rfc822 format available.

Message #8 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: divoplade <d <at> divoplade.fr>
Cc: 44130 <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Fri, 23 Oct 2020 15:12:44 +0200
Hi!

divoplade <d <at> divoplade.fr> skribis:

> I need this mkdir-p function in any non-trivial program I write. I had
> 3 bad choices:
>
> 1. Lobby guile to provide this function out of the box (this will take
> time);
> 2. Copy that of guix, or gash, or any other: this does not seem
> acceptable to me, because this function will surely evolve (for
> instance, if guile gets suport for mingw and we start running guile
> programs on windows) and I don't want to update more than one version
> of this function;
> 3. Depend on guix, gash or another package: this would be too large a
> dependency for my programs.
>
> So I wrote it in its own package and I intend to depend on it for my
> other projects. It would be best if you could accept this package in
> guix proper.
>
> What do you think?

I have nothing against adding this package to Guix, but…

Do you realize that the package definition is longer than the ‘mkdir-p’
procedure itself?  :-)

I think npm packages are too fine-grain; I don’t think this is the
approach to follow for Guile.

It’s likely that packages that need ‘mkdir-p’ also need other high-level
file system operations that Gash (say) provides.  In that case, I’d
encourage people to depend on Gash.  If Gash is too big a dependency for
the project, including its own copy of this 24-line procedure is
probably acceptable.

All that said, I do think that Guile itself should eventually include
some of the utilities found in (guix build utils) or Gash.  For
instance, it recently got a new ‘pipeline’ procedure, which comes from
Gash, and I think it’s a great addition.  This is the way to go in the
longer term.

Thoughts?

Ludo’.




Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 14:15:02 GMT) Full text and rfc822 format available.

Message #11 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: divoplade <d <at> divoplade.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 44130 <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Fri, 23 Oct 2020 16:14:42 +0200
Hi,

Le vendredi 23 octobre 2020 à 15:12 +0200, Ludovic Courtès a écrit :
> It’s likely that packages that need ‘mkdir-p’ also need other high-
> level
> file system operations that Gash (say) provides.  In that case, I’d
> encourage people to depend on Gash.  If Gash is too big a dependency
> for
> the project, including its own copy of this 24-line procedure is
> probably acceptable.

This function is needed for nearly all desktop applications. In the
freedesktop.org world of specifications, your application should store
data in different places in the home directory of the user. The
application data, such as your bookmarks, should be stored in
$XDG_DATA_HOME/<app>/, or $HOME/.local/share/<app>/ if XDG_DATA_HOME is
not set. So if that's a fresh system, or you want to have different
folders in your application data, you will need to make sure that an
arbitrary long chain of directories exist before writing your files.
You can't expect a static chain of directories, since you have to rely
on an environment variable. This is one example, but as a general rule,
whenever you want to write to a file, guile will create it if it does
not exist, because the intent is "do whatever it takes to have that
file and let me write to it".

As I explained, copying the function is not a good thing, because it
will need to adapt. If not a package, the solution could take the form
of a gnulib for guile (which makes little sense since the whole guile
is the standard library), or...

> All that said, I do think that Guile itself should eventually include
> some of the utilities found in (guix build utils) or Gash.

I really think that would be the ideal solution. I understand that you
don't want my package (to be fair, I'm not satisfied with one-package-
per-function either), but the need for that particular function exceeds
that of most other from guix build utils or gash.

Look, even guix itself does not care about mkdir! I get 481 instances
of '(mkdir ' in the source, for 1317 instances of '(mkdir-p '. That
should say something about having a mkdir function by default, but not 
mkdir-p. The only functions from guix build utils that have more than
100 calls (detected as '(fun ') are with-directory-excursion (616),
install-file (1018) (half of its job being mkdir-p), copy-recursively
(559), delete-file-recursively (470), find-files (1161), which (1423,
that's more than mkdir-p), modify-phases (4556, that's a lot more but
it's very specific to guix), substitute* (4240, same), wrap-program
(311, same), and invoke (2242). So I think if you want to import one
function from guix build utils into guile, start with mkdir-p!

Best regards,

divoplade





Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 16:38:02 GMT) Full text and rfc822 format available.

Message #14 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: divoplade <d <at> divoplade.fr>
Cc: 44130 <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Fri, 23 Oct 2020 18:37:20 +0200
Maybe I wasn’t clear enough but I don’t need to be convinced about the
usefulness of ‘mkdir-p’ and friends—I totally agree with you!

What I was questioning is the temptation to make one-function packages
as is common for instance in npm.

Thanks,
Ludo’.




Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 17:13:02 GMT) Full text and rfc822 format available.

Message #17 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: divoplade <d <at> divoplade.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 44130 <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Fri, 23 Oct 2020 19:12:17 +0200
Le vendredi 23 octobre 2020 à 18:37 +0200, Ludovic Courtès a écrit :
> 
> What I was questioning is the temptation to make one-function
> packages
> as is common for instance in npm.

Ah, so I can summarize. My solutions are:

1. Guile provides mkdir-p: Perfect!
2. I put the function in a package: not great, but acceptable.
3. I depend on gash: not acceptable, there's only mkdir-p that's
interesting, the rest is for advanced system tools.
4. I copy that function around: not acceptable.

So, there's no temptation to make one-function packages.

Should I understand that you question the integration of one-function
packages into guix? If you don't want it in guix, then it's fine, I can
just use it only for myself, I have my own channel. In which case,
please just say so, so we can all move on to more interesting things.

Best regards,

divoplade





Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 19:38:02 GMT) Full text and rfc822 format available.

Message #20 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: divoplade <d <at> divoplade.fr>
Cc: 44130 <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Fri, 23 Oct 2020 21:36:59 +0200
salut,

On Thu, 22 Oct 2020 at 01:29, divoplade <d <at> divoplade.fr> wrote:

> 1. Lobby guile to provide this function out of the box (this will take
> time);

This path seems the one to go.  It will take less time than running
Guile on Windows. ;-)

The only issue is that your code will depend on Guile 3.0.x where x>4.  

Otherwise, why is it not possible to send a patch to Guile?


> 2. Copy that of guix, or gash, or any other: this does not seem
> acceptable to me, because this function will surely evolve (for
> instance, if guile gets suport for mingw and we start running guile
> programs on windows) and I don't want to update more than one version
> of this function;

The ’mkdir-p’ version in (guix build utils) is the same as 2012.  So I
am not convinced that you will need to update it really often.


> 3. Depend on guix, gash or another package: this would be too large a
> dependency for my programs.

Ok.


On Fri, 23 Oct 2020 at 19:12, divoplade <d <at> divoplade.fr> wrote:

> So, there's no temptation to make one-function packages.

One package making one-function package will call other one-function
packages. :-)


à tantôt,
simon




Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 20:02:02 GMT) Full text and rfc822 format available.

Message #23 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: d <at> divoplade.fr
Cc: 44130 <at> debbugs.gnu.org
Subject: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Fri, 23 Oct 2020 22:01:33 +0200
> Le vendredi 23 octobre 2020 à 18:37 +0200, Ludovic Courtès a écrit :
> > 
> > What I was questioning is the temptation to make one-function
> > packages
> > as is common for instance in npm.
> 
> Ah, so I can summarize. My solutions are:
> 
> 1. Guile provides mkdir-p: Perfect!
> 2. I put the function in a package: not great, but acceptable.
> 3. I depend on gash: not acceptable, there's only mkdir-p that's
> interesting, the rest is for advanced system tools.
> 4. I copy that function around: not acceptable.
5. You depend on any other package, that provides mkdir-p among other
utilities big enough to be packaged in Guix: Not acceptable.
6. You depend on any other package, that provides just mkdir-p with
maybe a few other utilities, that make Guix devs question whether this
will become the next npm.
7. You write a module, that evals untrusted code from the internet and
point it towards your implementation of mkdir-p.
8. You find existing implementations of mkdir-p insufficient and roll
yet another mkdir-p.
9. You write an accelerated mkdir-p in native code as a shared library.
10. You combine 7 and 9.
...

For what it's worth, I've been hacking on a slightly more complete set
of filesystem utilities over at [1] for the past few days.  It is not
yet complete to the point that I'd consider its inclusion into Guix
upstream, but you might want to try it out and perhaps contribute if
that fits your niche.

> So, there's no temptation to make one-function packages.
> 
> Should I understand that you question the integration of one-function
> packages into guix? If you don't want it in guix, then it's fine, I
> can
> just use it only for myself, I have my own channel. In which case,
> please just say so, so we can all move on to more interesting things.
In that case, you still recreate npm, just with an additional layer of
indirection.  Obviously Guix developers can not stop you from doing so,
only advise you not to.

Regards, Leo

[1] https://gitlab.com/leoprikler/guile-filesystem






Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 22:01:02 GMT) Full text and rfc822 format available.

Message #26 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: divoplade <d <at> divoplade.fr>
To: bug-guile <at> gnu.org
Cc: zimoun <zimon.toutoune <at> gmail.com>, 44130 <at> debbugs.gnu.org
Subject: Recursive mkdir
Date: Sat, 24 Oct 2020 00:00:08 +0200
[Message part 1 (text/plain, inline)]
Dear guile,

I have slightly modified the mkdir function so that it takes a third
argument to try to create the intermediate directories when calling
mkdir, in effect acting as "mkdir -p".

However, I could not make the test suite run the ports test, on which I
added the test for the new behavior. Is it expected? How do I run it?

In the mean time, here is the WIP version of the patch.

Best regards,

divoplade

Le vendredi 23 octobre 2020 à 21:36 +0200, zimoun a écrit :
> salut,
> 
> On Thu, 22 Oct 2020 at 01:29, divoplade <d <at> divoplade.fr> wrote:
> 
> > 1. Lobby guile to provide this function out of the box (this will
> > take
> > time);
> 
> This path seems the one to go.  It will take less time than running
> Guile on Windows. ;-)
> 
> The only issue is that your code will depend on Guile 3.0.x where
> x>4.  
> 
> Otherwise, why is it not possible to send a patch to Guile?
[0001-mkdir-Add-an-optional-argument-recursive-to-create-t.patch (text/x-patch, attachment)]

Information forwarded to guix-patches <at> gnu.org:
bug#44130; Package guix-patches. (Fri, 23 Oct 2020 22:12:01 GMT) Full text and rfc822 format available.

Message #29 received at 44130 <at> debbugs.gnu.org (full text, mbox):

From: divoplade <d <at> divoplade.fr>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 44130 <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Sat, 24 Oct 2020 00:11:16 +0200
Le vendredi 23 octobre 2020 à 21:36 +0200, zimoun a écrit :
> salut,
> 
> On Thu, 22 Oct 2020 at 01:29, divoplade <d <at> divoplade.fr> wrote:
> 
> > 1. Lobby guile to provide this function out of the box (this will
> > take
> > time);
> 
> This path seems the one to go.  It will take less time than running
> Guile on Windows. ;-)
> 
> The only issue is that your code will depend on Guile 3.0.x where
> x>4.  
> 
> Otherwise, why is it not possible to send a patch to Guile?

The discussion continues here, in order to send the desired patch to
guile: 44186 <at> debbugs.gnu.org





Reply sent to Ludovic Courtès <ludo <at> gnu.org>:
You have taken responsibility. (Mon, 26 Oct 2020 16:58:02 GMT) Full text and rfc822 format available.

Notification sent to divoplade <d <at> divoplade.fr>:
bug acknowledged by developer. (Mon, 26 Oct 2020 16:58:02 GMT) Full text and rfc822 format available.

Message #34 received at 44130-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: divoplade <d <at> divoplade.fr>
Cc: 44130-done <at> debbugs.gnu.org
Subject: Re: [bug#44130] [PATCH] Add a recursive version of mkdir-p
Date: Mon, 26 Oct 2020 17:57:50 +0100
[Message part 1 (text/plain, inline)]
Hello!

divoplade <d <at> divoplade.fr> skribis:

> Le vendredi 23 octobre 2020 à 18:37 +0200, Ludovic Courtès a écrit :
>> 
>> What I was questioning is the temptation to make one-function
>> packages
>> as is common for instance in npm.
>
> Ah, so I can summarize. My solutions are:
>
> 1. Guile provides mkdir-p: Perfect!

Yes, we can work towards that goal.

> 2. I put the function in a package: not great, but acceptable.
> 3. I depend on gash: not acceptable, there's only mkdir-p that's
> interesting, the rest is for advanced system tools.
> 4. I copy that function around: not acceptable.

I agree that #4 is suboptimal, but I think you’re overstating it.

> So, there's no temptation to make one-function packages.

Well…  :-)

> Should I understand that you question the integration of one-function
> packages into guix? If you don't want it in guix, then it's fine, I can
> just use it only for myself, I have my own channel. In which case,
> please just say so, so we can all move on to more interesting things.

No no, like I wrote, I’m fine adding the ‘mkdir-p’ package, no problem;
the project currently has no guideline against one-function packages.

Anyway, I’ve applied the patch with the cosmetic changes below.

Thanks!

Ludo’.

[Message part 2 (text/x-patch, inline)]
diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index e3f547412b..d09e8d9737 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -4016,12 +4016,14 @@ errors.")
        (method git-fetch)
        (uri (git-reference
              (url "https://code.divoplade.fr/mkdir-p.git")
-             (commit "83e955ba612369336a69fe50fe023ad14fbe5d7c")))
-       (sha256 (base32 "01k20rjcv6p0spmw8ls776aar6bfw0jxw46d2n12w0cb2p79xjv8"))
+             (commit (string-append "v" version))))
+       (sha256
+        (base32 "01k20rjcv6p0spmw8ls776aar6bfw0jxw46d2n12w0cb2p79xjv8"))
+       (file-name (git-file-name name version))
        (snippet
         `(begin
            (with-output-to-file ".tarball-version"
-             (lambda _ (format #t "~a~%" "1.0.1")))
+             (lambda _ (format #t "~a~%" ,version)))
            #t))))
     (build-system gnu-build-system)
     (arguments `())
@@ -4034,14 +4036,12 @@ errors.")
        ("pkg-config" ,pkg-config)
        ("gettext" ,gnu-gettext)))
     (inputs `(("guile" ,guile-3.0)))
-    (propagated-inputs
-     `(("guile" ,guile-3.0)))
-    (synopsis "Implementation of a recursive mkdir for guile")
+    (synopsis "Implementation of a recursive @code{mkdir} for Guile")
     (description
-     "This package provides within the (mkdir-p) module the mkdir-p function
-that tries to create the chain of directories recursively.  It also provides
-new versions of open-output-file, call-with-output-file and
-with-output-to-file to create the directory of its argument if it does not
-exist.")
+     "This package provides within the @code{(mkdir-p)} module the
+@code{mkdir-p} function that tries to create the chain of directories
+recursively.  It also provides new versions of @code{open-output-file},
+@code{call-with-output-file} and @code{with-output-to-file} to create the
+directory of its argument if it does not exist.")
     (home-page "https://mkdir-p.divoplade.fr")
     (license license:asl2.0)))

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 24 Nov 2020 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 125 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.