Re: Reusing code for a build-phase?

[Csepp]

Hartmut Goebel  writes:

> Hi,
>
> I'm currently packaging vagrant and some plugins. For all plugins an 
> additional phase is required, generating a json file, see below. Since this 
> is quite
> some code, I'd like to put it into some definition or some wrapper. Since it 
> uses (this-package-verion), my attempts failed.
>
> At best, a plugin would then be defined like
>
>   (define-public vagrant-abc (vagrant-plugin-wrapper (package …
>
> Anyhow I'd be happy to when being able to use some function in the phase 
> instead of duplicating the code.
>
> Any ideas? Many thanks in advance
>
> (arguments
>  (list
>   #:tests? #f ; tests involve running vagrant and downloading a box
>   #:phases
>   #~(modify-phases %standard-phases
>   (add-after 'install 'install-plugin.json
> (lambda _
>   (let* ((plugins.d (string-append
>  #$output "/share/vagrant-plugins/plugins.d"))
>  (plugin.json (string-append
>plugins.d "/" #$name ".json")))
> (mkdir-p plugins.d)
> #$(with-extensions (list guile-json-4)
> #~(begin
> (use-modules (json))
> (call-with-output-file plugin.json
>   (lambda (port)
> (scm->json
>  '((#$name
> .
> (("ruby_version"
>   . #$(package-version (this-package-input 
> "ruby")))
>  ("vagrant_version"
>   . #$(package-version (this-package-input 
> "vagrant")))
>  ("gem_version" .  "")
>  ("require" . "")
>  ("sources" . #()
>  port)))

Maybe you could create a build system that inherits from the one these
packages use, but adds the extra phase.

Re: Reusing code for a build-phase?

[Hartmut Goebel]

Am 06.08.23 um 14:49 schrieb Csepp:

Maybe you could create a build system that inherits from the one these
packages use, but adds the extra phase.


I was thinking about this, too. But this seems to be too much, as there 
are not hundreds of Vagrant plugins. Also a build-system requires 
documentation, wich is another pile of work.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Reusing code for a build-phase?

[Bruno Victal]

Hi Hartmut,

On 2023-08-05 09:25, Hartmut Goebel wrote:
> Hi,
> 
> I'm currently packaging vagrant and some plugins. For all plugins an 
> additional phase is required, generating a json file, see below. Since this 
> is quite some code, I'd like to put it into some definition or some wrapper. 
> Since it uses (this-package-verion), my attempts failed.
> 
> At best, a plugin would then be defined like
> 
>   (define-public vagrant-abc (vagrant-plugin-wrapper (package …
> 
> Anyhow I'd be happy to when being able to use some function in the phase 
> instead of duplicating the code.
> 
> Any ideas? Many thanks in advance

I think using a procedure like you're suggesting here would be alright for this.
Perhaps  could serve as inspiration?


-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.

Re: The package/inherit trap

[Mark H Weaver]

Simon Tournier  writes:

> Hi Tobias,
>
> On Tue, 07 Mar 2023 at 22:11, Tobias Geerinckx-Rice  wrote:
>
>> However, merely documenting something is not enough when we have the
>> chance to fix misleading naming, as we do here.  It would be nice to
>> have, but orthogonal. 
>
> I would not say it is orthogonal because renaming would not have been
> enough, at least for me, in order to get the difference with ’inherit’.
>
> For sure, it is a real trap. :-)  For instance,
>
> $ git log --grep='package/inherit' --oneline | grep use
> 5f83dd03a2 gnu: kodi/wayland: Do not use package/inherit.
> 6ecf88a6a1 gnu: poppler-next: Don't use 'package/inherit'.
> 5a5b729d66 gnu: abseil-cpp: Don't use 'package/inherit'.
> dbcf2b61b1 gnu: Fix erroneous uses of 'package/inherit'.
> 2f97a666a5 gnu: python-urllib3: Don't use 'package/inherit' on 
> replacement package.
> 4163b6d855 gnu: avahi: Don't use package/inherit.
>
> and in the light of this discussion, 5f83dd03a2 seems incorrect, no?

I agree that commit 5f83dd03a2 is incorrect.  'kodi/wayland' is quite
clearly a case where 'package/inherit' should be used.

   Mark

Re: The package/inherit trap (was: gnu: stellarium: Enable ShowMySky.)

[(]

Tobias Geerinckx-Rice  writes:
> But I'll gladly judge other bikesheds if they lead to a less misleading name.

How about 'package/variant' or 'package/variant-of'?

  -- (

Re: The package/inherit trap (was: gnu: stellarium: Enable ShowMySky.)

[Attila Lendvai]

> How about 'package/variant' or 'package/variant-of'?

+1 for trying to capture the intention in the name, instead of the means of 
implementation.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Although teachers do care and do work very, very hard, the institution is 
psychopathic-it has no conscience. It rings a bell and the young man in the 
middle of writing a poem must close his notebook and move to a different cell 
where he must memorize that humans and monkeys derive from a common ancestor.”
— John Taylor Gatto (1935–2018), 'Dumbing Us Down: The Hidden 
Curriculum of Compulsory Education' (1992)