poetry: python-poetry?

poetry: python-poetry?

[Andy Tai]

curious poetry is not named python-poetry in Guix as following
convention of most python packages

Re: poetry: python-poetry?

[Andreas Enge]

Am Wed, Jul 26, 2023 at 09:25:43PM -0700 schrieb Andy Tai:
> curious poetry is not named python-poetry in Guix as following
> convention of most python packages

See here:
   https://guix.gnu.org/de/manual/devel/en/html_node/Python-Modules.html

The idea is that "libraries" (or "modules") start with python-, while
"applications" do not emphasize the language they are written in. Calibre,
for instance, also is not called python-calibre.

Of course with script languages there is no clear technical barrier;
but a package with lots of binaries will not start with python-, while
software that is mainly used in lines "import xyz;" tends to be called
python-something.

Andreas

Re: poetry: python-poetry?

[Lars-Dominik Braun]

Hi Andy,

> curious poetry is not named python-poetry in Guix as following
> convention of most python packages

packages providing a binary instead of a library usually skip the
language-specific prefix, because the programming language does
not matter in that case.

Lars

Re: poetry: python-poetry?

[Wojtek Kosior via Development of GNU Guix and the GNU System distribution.]

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

> The idea is that "libraries" (or "modules") start with python-, while
> "applications" do not emphasize the language they are written in. Calibre,
> for instance, also is not called python-calibre.

In this case it seems there are quite a few packages that go against
this convention. 'python-pip', for example, is mostly used as a CLI
*application*.

This has been actually causing me confusion. At some point I was
wondering how I should call a package I was writing and it seems I
erroneously added "python-" taking example from other packages :/

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Thu, 27 Jul 2023 08:56:32 +0200 Andreas Enge <andreas@enge.fr> wrote:

> Am Wed, Jul 26, 2023 at 09:25:43PM -0700 schrieb Andy Tai:
> > curious poetry is not named python-poetry in Guix as following
> > convention of most python packages  
> 
> See here:
>    https://guix.gnu.org/de/manual/devel/en/html_node/Python-Modules.html
> 
> The idea is that "libraries" (or "modules") start with python-, while
> "applications" do not emphasize the language they are written in. Calibre,
> for instance, also is not called python-calibre.
> 
> Of course with script languages there is no clear technical barrier;
> but a package with lots of binaries will not start with python-, while
> software that is mainly used in lines "import xyz;" tends to be called
> python-something.
> 
> Andreas
> 
> 

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

Re: poetry: python-poetry?

[Hilton Chain]

Hi,

On Fri, 28 Jul 2023 02:10:38 +0800,
Wojtek Kosior via Development of GNU Guix and the GNU System distribution. wrote:
>
> [1  <text/plain; UTF-8 (quoted-printable)>]
> > The idea is that "libraries" (or "modules") start with python-, while
> > "applications" do not emphasize the language they are written in. Calibre,
> > for instance, also is not called python-calibre.
>
> In this case it seems there are quite a few packages that go against
> this convention. 'python-pip', for example, is mostly used as a CLI
> *application*.
>
> This has been actually causing me confusion. At some point I was
> wondering how I should call a package I was writing and it seems I
> erroneously added "python-" taking example from other packages :/

I think we can define library and CLI program separately, since Python
libraries usually need to propagate some inputs, while CLI programs in
/bin and /sbin do not, as they are wrapped by the build system.

--8<---------------cut here---------------start------------->8---
(define-public python-xxx
  (package
    (name "python-xxx")
    (propagated-inputs (list [...]))
    [...]))

(define-public xxx
  (package
    (inherit python-xxx)
    (name "xxx")
    (propagated-inputs '())
    (inputs (package-propagated-inputs python-xxx))
    [...]))
--8<---------------cut here---------------end--------------->8---

Thanks

Re: poetry: python-poetry?

[Hilton Chain]

Hi,

On Fri, 28 Jul 2023 02:10:38 +0800,
Wojtek Kosior via Development of GNU Guix and the GNU System distribution. wrote:
>
> [1  <text/plain; UTF-8 (quoted-printable)>]
> > The idea is that "libraries" (or "modules") start with python-, while
> > "applications" do not emphasize the language they are written in. Calibre,
> > for instance, also is not called python-calibre.
>
> In this case it seems there are quite a few packages that go against
> this convention. 'python-pip', for example, is mostly used as a CLI
> *application*.
>
> This has been actually causing me confusion. At some point I was
> wondering how I should call a package I was writing and it seems I
> erroneously added "python-" taking example from other packages :/

I think we can define library and CLI program separately, since Python
libraries usually need to propagate some inputs, while CLI programs in
/bin and /sbin do not, as they are wrapped by the build system.

--8<---------------cut here---------------start------------->8---
(define-public python-xxx
  (package
    (name "python-xxx")
    (propagated-inputs (list [...]))
    [...]))

(define-public xxx
  (package
    (inherit python-xxx)
    (name "xxx")
    (propagated-inputs '())
    (inputs (package-propagated-inputs python-xxx))
    [...]))
--8<---------------cut here---------------end--------------->8---

Thanks

Re: poetry: python-poetry?

[Hartmut Goebel]

Am 31.07.23 um 04:05 schrieb Hilton Chain:
> I think we can define library and CLI program separately, since Python
> libraries usually need to propagate some inputs, while CLI programs in
> /bin and /sbin do not, as they are wrapped by the build system.

I like the idea of "hiding" dependencies behind the script and not have 
them pollute the library path. And indeed I just thought about something 
like this when packaging vagrant (which is a rube-program).

If we implement such a thing, IMHO it should become a wrapper function, 
doing all the magic, so the program would defined as simple as

(define-public xxx
     (python-scripts-from-package
        python-xxx
        "xxx" "xxx3" "xxx-admin"))   ; selecting scripts might be 
useful/necessary

And of course we should start providing such a thing for other 
languages, too.

-- 
Regards
Hartmut Goebel

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