Message ID | 6ff632f5c1e378647cecc7177b7018fb8a0ee6d4.camel@divoplade.fr |
---|---|
State | Accepted |
Headers | show |
Series | [bug#44130] Add a recursive version of mkdir-p | expand |
Context | Check | Description |
---|---|---|
cbaines/issue | success | View issue |
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | fail | View Laminar job |
Hi! divoplade <d@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’.
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
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’.
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
salut, On Thu, 22 Oct 2020 at 01:29, divoplade <d@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@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
> 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
Le vendredi 23 octobre 2020 à 21:36 +0200, zimoun a écrit : > salut, > > On Thu, 22 Oct 2020 at 01:29, divoplade <d@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@debbugs.gnu.org
From 1a1798a99b09ef7df0f183d99ea9a4717b9406d7 Mon Sep 17 00:00:00 2001 From: divoplade <d@divoplade.fr> Date: Thu, 22 Oct 2020 01:14:27 +0200 Subject: [PATCH] Add guile-mkdir-p As there is no guile function to create directories recursively, a lot of packages bundle their own. For instance, Guile as Shell or Guix. This also happens to me, as I need this function in any substantial program. --- gnu/packages/guile-xyz.scm | 39 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm index 88c0586dc9..2504deb3af 100644 --- a/gnu/packages/guile-xyz.scm +++ b/gnu/packages/guile-xyz.scm @@ -4007,3 +4007,42 @@ features not found in the standard read procedure such as a compatible mode with support for other RnRS standards and a tolerant mode that continues on errors.") (license license:expat))) + +(define-public guile-mkdir-p + (package + (name "guile-mkdir-p") + (version "1.0.1") + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://code.divoplade.fr/mkdir-p.git") + (commit "83e955ba612369336a69fe50fe023ad14fbe5d7c"))) + (sha256 (base32 "01k20rjcv6p0spmw8ls776aar6bfw0jxw46d2n12w0cb2p79xjv8")) + (snippet + `(begin + (with-output-to-file ".tarball-version" + (lambda _ (format #t "~a~%" "1.0.1"))) + #t)))) + (build-system gnu-build-system) + (arguments `()) + (native-inputs + `(("guile" ,guile-3.0) + ("texinfo" ,texinfo) + ("autoconf" ,autoconf) + ("autoconf-archive" ,autoconf-archive) + ("automake" ,automake) + ("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") + (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.") + (home-page "https://mkdir-p.divoplade.fr") + (license license:asl2.0))) -- 2.28.0