Package's inputs for developer?

Package's inputs for developer?

[Olivier Dion via Development of GNU Guix and the GNU System distribution.]

Hi Guix,

I often find my self using inheritance of package to add native-inputs
that are not stricly necessary for building the project, but are used
for developement purpose like so:
-------------------------------------------------
(define base-native-inputs (list ...))

(define my-package
  (package
    ...
    (native-inputs base-native-inputs)
    ...))

;; Developers version
(package
  (inherit my-package)
  (native-inputs
    (append base-native-inputs
            (list gdb lcov))))
-------------------------------------------------

I guess this is the correct way of doing it or perhaps I should put gdb
and lcov in the base-native-inputs?.  But I was thinking that perhaps
something like `(developer-inputs (list gdb lcov))` would be better,
since these inputs are not stricly necessary for building the package.

Regards,
old

-- 
Olivier Dion
Polymtl

Re: Package's inputs for developer?

[Kaelyn]

Hello,

On Sunday, March 6th, 2022 at 8:19 AM, Olivier Dion via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:

> Hi Guix,
>
> I often find my self using inheritance of package to add native-inputs
>
> that are not stricly necessary for building the project, but are used
>
> for developement purpose like so:
>
> -------------------------------------------------
>
> (define base-native-inputs (list ...))
>
> (define my-package
>
> (package
>
> ...
>
> (native-inputs base-native-inputs)
>
> ...))
>
> ;; Developers version
>
> (package
>
> (inherit my-package)
>
> (native-inputs
>
> (append base-native-inputs
>
> (list gdb lcov))))
>
> -------------------------------------------------
>
> I guess this is the correct way of doing it or perhaps I should put gdb
>
> and lcov in the base-native-inputs?. But I was thinking that perhaps
>
> something like `(developer-inputs (list gdb lcov))` would be better,
>
> since these inputs are not stricly necessary for building the package.

Can you give a bit more detail about what the use case is for adding developer tools as inputs?

The inheritance you describe seems more cumbersome than simply doing `guix shell gdb lcov -D my-package` to enter a development environment with gdb and lcov present, while also being a bit more limited when there are multiple tools with a similar function. In the above example, imagine if a developer wants to debug my-package using lldb instead of gdb--the developer-inputs would require transforming the package definition, but the ad-hoc invocation could simply be `guix shell lldb lcov -D my-package`.

Cheers,
Kaelyn

>
> Regards,
>
> old
>
> --
>
> Olivier Dion
>
> Polymtl

Re: Package's inputs for developer?

[Olivier Dion via Development of GNU Guix and the GNU System distribution.]

On Mon, 07 Mar 2022, Kaelyn <kaelyn.alexi@protonmail.com> wrote:
> On Sunday, March 6th, 2022 at 8:19 AM, Olivier Dion via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:
>
>> Hi Guix,
>>
>> I often find my self using inheritance of package to add native-inputs
>>
>> that are not stricly necessary for building the project, but are used
>>
>> for developement purpose like so:
>>
>> -------------------------------------------------
>>
>> (define base-native-inputs (list ...))
>>
>> (define my-package
>>
>> (package
>>
>> ...
>>
>> (native-inputs base-native-inputs)
>>
>> ...))
>>
>> ;; Developers version
>>
>> (package
>>
>> (inherit my-package)
>>
>> (native-inputs
>>
>> (append base-native-inputs
>>
>> (list gdb lcov))))
>>
>> -------------------------------------------------
>>
>> I guess this is the correct way of doing it or perhaps I should put gdb
>>
>> and lcov in the base-native-inputs?. But I was thinking that perhaps
>>
>> something like `(developer-inputs (list gdb lcov))` would be better,
>>
>> since these inputs are not stricly necessary for building the package.
>
> Can you give a bit more detail about what the use case is for adding
> developer tools as inputs?

Only for convenience of developing.  I also use the developer inputs for
continuous integration for generating coverage report for example.  I
guess that all of this can be wrapped under a script such as
`development-env` and use `guix shell` in it.

> The inheritance you describe seems more cumbersome than simply doing
> `guix shell gdb lcov -D my-package` to enter a development environment
> with gdb and lcov present, while also being a bit more limited when
> there are multiple tools with a similar function. In the above
> example, imagine if a developer wants to debug my-package using lldb
> instead of gdb--the developer-inputs would require transforming the
> package definition, but the ad-hoc invocation could simply be `guix
> shell lldb lcov -D my-package`.

I agree it's not very flexible.  I basically impose the usage of GDB
for debugging here.  I guess that using `guix shell` is the correct way
of doing so then.

Regards,
old

-- 
Olivier Dion
Polymtl

Re: Package's inputs for developer?

[zimoun]

Hi,

> I guess this is the correct way of doing it or perhaps I should put gdb
> and lcov in the base-native-inputs?.  But I was thinking that perhaps
> something like `(developer-inputs (list gdb lcov))` would be better,
> since these inputs are not stricly necessary for building the package.

Well, this list of 'developer-inputs' seems a personal choice or could
be considered as 'recommended'.  Well, I am not convinced it would be
useful but maybe the right level is to add something to 'properties'.

Anyway.


Usually my workflow is:

    guix shell gdb lcov -D my-package

and if it is often the same set of packages, I use a manifest.


Cheers,
simon

Re: Package's inputs for developer?

[Olivier Dion via Development of GNU Guix and the GNU System distribution.]

On Tue, 08 Mar 2022, zimoun <zimon.toutoune@gmail.com> wrote:
> Hi,
>
>> I guess this is the correct way of doing it or perhaps I should put gdb
>> and lcov in the base-native-inputs?.  But I was thinking that perhaps
>> something like `(developer-inputs (list gdb lcov))` would be better,
>> since these inputs are not stricly necessary for building the package.
>
> Well, this list of 'developer-inputs' seems a personal choice or could
> be considered as 'recommended'.  Well, I am not convinced it would be
> useful but maybe the right level is to add something to 'properties'.

I had more a recommended workflow in mind.  For example, I have a bunch
of scripts under `tools/` for compiling and testing the project within
Emacs.  And they all use these developer inputs.  I find this useful if
for example someone wants to quickly debug the program from source
without searching too much on how to do so.  Just fire your text editor
and voila.

>     guix shell gdb lcov -D my-package
>
> and if it is often the same set of packages, I use a manifest.

Yes this is what I also but I wrapped it in a script.  And how do you
indicate the "-D" in your manifest?

-- 
Olivier Dion
Polymtl

Re: Package's inputs for developer?

[Danny Milosavljevic]

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

Hi,

On Sun, 06 Mar 2022 11:19:58 -0500
Olivier Dion via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> wrote:

> I often find my self using inheritance of package to add native-inputs
> that are not stricly necessary for building the project, but are used
> for developement purpose:

It's very common to require extra tools for development, but those are
anything but standardized. In fact, finding elusive bugs is very much
helped by using different compiler versions, compiler vendors etc.

So I don't think adding those (which?) directly in the base package is a good idea.

Better:

$ guix shell -f guix.scm gdb@11.1 lcov

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Package's inputs for developer?

[zimoun]

Hi,

On Tue, 8 Mar 2022 at 17:45, Olivier Dion <olivier.dion@polymtl.ca> wrote:
> On Tue, 08 Mar 2022, zimoun <zimon.toutoune@gmail.com> wrote:

> I had more a recommended workflow in mind.  For example, I have a bunch
> of scripts under `tools/` for compiling and testing the project within
> Emacs.  And they all use these developer inputs.  I find this useful if
> for example someone wants to quickly debug the program from source
> without searching too much on how to do so.  Just fire your text editor
> and voila.

If 'tools/' is a directory from upstream, then maybe the
recommendation would be to directly add a guix.scm file containing the
material for jumping in development.


> >     guix shell gdb lcov -D my-package
> >
> > and if it is often the same set of packages, I use a manifest.
>
> Yes this is what I also but I wrapped it in a script.  And how do you
> indicate the "-D" in your manifest?

Well, 'package-development-inputs' from (guix packages) should fit the
job, I guess.


Cheers,
simon

Re: Package's inputs for developer?

[Liliana Marie Prikler]

Hi Olivier,

Am Sonntag, dem 06.03.2022 um 11:19 -0500 schrieb Olivier Dion via
Development of GNU Guix and the GNU System distribution.:
> Hi Guix,
> 
> I often find my self using inheritance of package to add native-inputs
> that are not stricly necessary for building the project, but are used
> for developement purpose like so:
> -------------------------------------------------
> (define base-native-inputs (list ...))
> 
> (define my-package
>   (package
>     ...
>     (native-inputs base-native-inputs)
>     ...))
> 
> ;; Developers version
> (package
>   (inherit my-package)
>   (native-inputs
>     (append base-native-inputs
>             (list gdb lcov))))
> -------------------------------------------------
> 
> I guess this is the correct way of doing it or perhaps I should put gdb
> and lcov in the base-native-inputs?.  But I was thinking that perhaps
> something like `(developer-inputs (list gdb lcov))` would be better,
> since these inputs are not stricly necessary for building the
> package.
Note, that manifests exist and you should use them.  An example (from
[1]):

--8<---------------cut here---------------start------------->8---
(use-modules [...])

(define %here (dirname (current-filename)))

(packages->manifest
 (cons*
  emacs emacs-geiser
  guile-hall
  (filter-map
   (match-lambda
     ((_ (? package? package) output) (list package output))
     ((_ (? package? package)) package)
     (else #f))
   (package-development-inputs
    (load (string-append %here "/guix.scm"))))))
--8<---------------cut here---------------end--------------->8---

This adds emacs, emacs-geiser and guile-hall to the package-
development-inputs of the package described in "./guix.scm" and
constructs an environment with all of them.

Cheers

[1] https://gitlab.com/spritely/guile-goblins/