Thanks for response, Paren

> Heya,
> 
> On Thu Oct 13, 2022 at 8:17 AM BST, Wojtek Kosior via wrote:
> > > guix environment -L . -e '(@ (hydrilla) hydrilla)' -- python3 -m build -s
> > > guix pack -L . -RR \
> > >     -S /hydrilla=bin/hydrilla \
> > >     -S /hydrilla-builder=bin/hydrilla-builder \
> > >     -S /hydrilla-server=bin/hydrilla-server \
> > >     -S /haketilo=bin/haketilo \
> > >     -e '(@ (hydrilla) hydrilla-dist-tarball)'  
> 
> I don't think this is an optimal way to use ``guix pack''. Surely this pack
> won't contain the Python modules that the script needs to import...?

Actually, the pack *does* contain all the necessary modules. Here I made
`hydrilla` resolve to a package that uses the entire contents of
project directory as its `(source)`. `hydrilla-dist-tarball` then
inherits from that package and causes a tarball under `./dist/` to
instead be used as `(source)`. All the `(propagated-inputs)` are there,
unmodified, in the child package.

Any other ideas what could be causing problems?

If you're curious, below I explain how I arrived at the commands I am
using. Note that this is almost certainly in no way related to how
console_script entries are found.

So, in my project I initially added a guix.scm[1] that I could
successfully use with `guix shell -Df guix.scm`. In guix.scm I
initially specified the source of "hydrilla" package as

> (source (local-file %source-dir
>                     #:recursive? #t
>                     #:select? (git-predicate %source-dir)))

with %source-dir defined as

> (define %source-dir (dirname (current-filename)))

This turned out not to work correctly for building the package because
the setuptools_scm python build plugin I am using relies on git
metadata to decide the version of the package and what files should
belong to it. Metadata from `.git/` is of course excluded with
`git-predicate`. Also, an attempt to get away without using the
`#:select?` keyword argument at all caused even weirder problems with
some .py files being included in Guix package as empty files...

Anyway, I figured out the best solution is to first generate a source
tarball with `python3 -m build -s`. Such tarball gets placed under
`./dist/` and already contains all the metadata prepared by
setuptools_scm. Hence, the alternative definition of package source[2]

> (source (local-file
>          (string-append %source-dir "/dist/" filename)))

with `filename` bound to an appropriate string...

This does work. But the tarball from beneath `./dist/` is what I
distribute to users. Why should someone who downloads that tarball need
to use the `python -m build -s`? There's no need. So I ended up making
2 variants of the package definition. One for release tarball users,
using `(local-file %source-dir #:recursive? #t)`. And one for git
checkout users.

Now, I was not aware of a good way to use 2 different definitions with
a simple guix.scm and `-f` option. Hence, I made it into a module and
renamed that to hydrilla.scm. Under normal circumstances I could
probably get away without using the `-e` option to guix. But here I
have 2 packages with the same name "hydrilla". To be able to choose
which one I want to use, I needed to refer to them by the names under
which they are exported from the module. Hence, the `-e` option.

Seeing how much confusion all this causes, I think I will stop caring
about release tarball users running an unnecessary
`python -m build -s`...

> Also, ``guix environment'' has been deprecated for a while now; consider using
> ``guix shell'':
> 
>   guix environment -L. hydrilla
>   # becomes
>   guix shell -DL. hydrilla
> 
> (``-D'' means "use the dependencies of the next listed package", as ``--ad-hoc''
> is the default behaviour of ``guix shell''.)
> 
>     -- (

I experienced guix shell failing to pick up changes I was making to
guix.scm. It seemed to be incorrectly using a cached version of that
file. Well, perhaps this behavior shall no longer occur when I use the
`-e` flag? Idk, I discovered that flag after swithing to
`guix environment`. Being now reminded about the deprecation (thanks!),
I think I'll give `guix shell` another chance, though :)

Best,
Wojtek

[1] https://git.koszko.org/pydrilla/tree/guix.scm?id=d42379c189c33dac732a1a1341395a9f5683260b
[2] https://git.koszko.org/pydrilla/tree/hydrilla.scm?h=v3.0-beta1

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!           #2: blessed Aniela Salawa
Poznaj świętych krakowskich!  #2: błogosławiona Aniela Salawa
https://pl.wikipedia.org/wiki/Aniela_Salawa
-- (sig_end)


On Thu, 13 Oct 2022 09:26:32 +0100
"(" <paren@disroot.org> wrote:

> Heya,
> 
> On Thu Oct 13, 2022 at 8:17 AM BST, Wojtek Kosior via wrote:
> > > guix environment -L . -e '(@ (hydrilla) hydrilla)' -- python3 -m build -s
> > > guix pack -L . -RR \
> > >     -S /hydrilla=bin/hydrilla \
> > >     -S /hydrilla-builder=bin/hydrilla-builder \
> > >     -S /hydrilla-server=bin/hydrilla-server \
> > >     -S /haketilo=bin/haketilo \
> > >     -e '(@ (hydrilla) hydrilla-dist-tarball)'  
> 
> I don't think this is an optimal way to use ``guix pack''. Surely this pack
> won't contain the Python modules that the script needs to import...?
> 
> Have you tried
> 
>   guix  pack -RL. hydrilla
> 
> ? Note that you don't actually need to use ``-e'', as the UI finds packages
> by scanning all the modules in the load path for public variables containing
> <package> objects.
> 
> Also, ``guix environment'' has been deprecated for a while now; consider using
> ``guix shell'':
> 
>   guix environment -L. hydrilla
>   # becomes
>   guix shell -DL. hydrilla
> 
> (``-D'' means "use the dependencies of the next listed package", as ``--ad-hoc''
> is the default behaviour of ``guix shell''.)
> 
>     -- (