Greetd autologin?

Greetd autologin?

[kiasoc5]

Hi Guix,

Is there a way to configure autologin for greetd yet?

Re: Greetd autologin?

[(]

On Thu Oct 13, 2022 at 7:26 AM BST, kiasoc5 wrote:
> Is there a way to configure autologin for greetd yet?

Not yet, but it should be fairly trivial to add,

  https://wiki.archlinux.org/title/Greetd#Enabling_autologin

    -- (

program prepared with `guix pack` unusable by end users

[Wojtek Kosior via]

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

Hello,

I'm developing a program, named Haketilo, in Python. I wanted to make it
available to users by the means of a tarball made with `guix pack`
(which seems like a marvelous feature, btw!). It worked well on my PC
but a user reported an error when running it[1]. The console_scripts
entry point of the program cannot be found by importlib.

User's entire report is behind the link[1] - I'll just quote the
relevant traceback of `./haketilo --version`

> Traceback (most recent call last):
>   File "/gnu/store/ziiryffcgph9jjcldz4rv2x5v6y0kxqh-hydrilla-3.0b1/bin/.haketilo-real", line 33, in <module>
>     sys.exit(load_entry_point('hydrilla==3.0b1', 'console_scripts', 'haketilo')())
>   File "/gnu/store/ziiryffcgph9jjcldz4rv2x5v6y0kxqh-hydrilla-3.0b1/bin/.haketilo-real", line 25, in importlib_load_entry_point
>     return next(matches).load()
> StopIteration

For an unknown reason, the user reports it works with sudo. Does anyone
have an idea what could be the cause?

I made the pack by running

> 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)'

in the git repo of my project[2] checked out to tag `v3.0-beta1`. The
Guix version used is 1.3.0-26.fd00ac7.

Any advice is appreciated :)

Best,
Wojtek

[1] https://hydrillabugs.koszko.org/issues/130
[2] https://git.koszko.org/pydrilla


-- (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!           #48: saint Szymon z Lipnicy
Poznaj świętych krakowskich!  #48: święty Szymon z Lipnicy
https://pl.wikipedia.org/wiki/Szymon_z_Lipnicy
-- (sig_end)

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

Re: program prepared with `guix pack` unusable by end users

[(]

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''.)

    -- (

Re: program prepared with `guix pack` unusable by end users

[Wojtek Kosior via]

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

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''.)
> 
>     -- (



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

Re: program prepared with `guix pack` unusable by end users

[zimoun]

Hi,

Is it related to the message [1] you are answering?

1: <https://yhetil.org/guix/CNKL38E5T0RV.1VYM8R2V0O1QM@guix-framework/>

If no, please start a new thread when it is a new topic. :-)



On jeu., 13 oct. 2022 at 09:17, Wojtek Kosior via <help-guix@gnu.org> wrote:

> I made the pack by running
>
>> 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)'

Why do you pack ’hydrilla-dist-tarball’ instead of just ’hydrilla’.

Guix should take care of everything; not necessary when packing a Python
bundle as you are doing.


Cheers,
simon