unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Types and builds for mypy
@ 2022-10-18 10:09 Philip Beadling
  2022-10-22 13:53 ` Maxim Cournoyer
  0 siblings, 1 reply; 4+ messages in thread
From: Philip Beadling @ 2022-10-18 10:09 UTC (permalink / raw)
  To: guix-devel@gnu.org

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

Hi all

Users of mypy and python will have noticed since the promotion of mypy to v0. 971 it is now neccesary to provide separate python packages containing types of non core libraries.

The way we've been collecting these, outside of Guix proper, is in a single module called python-types, which can then simply be added as a native-input to any python build requiring mypy.

The alternative is to colocate the types with their packages, or perhaps colocate them all with mypy itself.

My preference is to put them all in one module, I think.

Is there formal strategy in Guix for how to organise these packages?  I'd be happy to make available our current python-types.scm as a starting point?

Finally and slightly related I note that by default the 971 package of mypy is not C compiled using mypyc.  It's a simple tweak to turn this on in the package and it makes huge performance difference when using mypy (on average 4x faster is quoted).  Again, happy to offer up a modified or inherited package if other people are frustrated by the slow down?


Cheers,
Phil.



[-- Attachment #2: Type: text/html, Size: 3119 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Types and builds for mypy
  2022-10-18 10:09 Types and builds for mypy Philip Beadling
@ 2022-10-22 13:53 ` Maxim Cournoyer
  2022-10-22 17:05   ` Phil
  0 siblings, 1 reply; 4+ messages in thread
From: Maxim Cournoyer @ 2022-10-22 13:53 UTC (permalink / raw)
  To: Philip Beadling; +Cc: guix-devel@gnu.org

Hi,

Philip Beadling <phil@beadling.co.uk> writes:

> Hi all
>
> Users of mypy and python will have noticed since the promotion of mypy to v0. 971 it is now neccesary to provide separate python packages containing types of non core libraries.
>
> The way we've been collecting these, outside of Guix proper, is in a single module called python-types, which can then simply be added as a native-input to any python build requiring mypy.
>
> The alternative is to colocate the types with their packages, or perhaps colocate them all with mypy itself.

Is MyPy the only consumer of Python type annotations?  I think so, but
I'm not sure.  If it's the only one, it'd make sense to move mypy and
all the annotation types to (gnu packages python-types), I think.

> My preference is to put them all in one module, I think.
>
> Is there formal strategy in Guix for how to organise these packages?  I'd be happy to make available our current python-types.scm as a starting point?
>
> Finally and slightly related I note that by default the 971 package of
> mypy is not C compiled using mypyc.  It's a simple tweak to turn this
> on in the package and it makes huge performance difference when using
> mypy (on average 4x faster is quoted).  Again, happy to offer up a
> modified or inherited package if other people are frustrated by the
> slow down?

I think if it doesn't negatively impact its use, we should go ahead and
make this change in the mypy package.

Happy to review patches!

-- 
Thanks,
Maxim


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Types and builds for mypy
  2022-10-22 13:53 ` Maxim Cournoyer
@ 2022-10-22 17:05   ` Phil
  2022-10-25 23:47     ` Maxim Cournoyer
  0 siblings, 1 reply; 4+ messages in thread
From: Phil @ 2022-10-22 17:05 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: guix-devel@gnu.org

Thanks for your reply Maxim,

Maxim Cournoyer writes:


> Is MyPy the only consumer of Python type annotations?  I think so, but
> I'm not sure.  If it's the only one, it'd make sense to move mypy and
> all the annotation types to (gnu packages python-types), I think.

Mypy is certainly a prominent consumer, but you're right - PEP 561 type stub
packages are also used by PyCharm, pytype, and I've heard CPython can
use them to compile, to name a few.

So I think my revised opinion is mypy should stay where it is, but I do
like the idea of keeping all the types in one module?

Co-locating them with the module they provide type for also works fine,
but I kinda see the type files as visual noise if we put them in
packages which are organized into categories they don't directly
contribute to. Perhaps they are better kept in once place?

It also means that when running mypy you can just import your
python-types module, and be sure it's going to work.


> I think if it doesn't negatively impact its use, we should go ahead and
> make this change in the mypy package.
>
> Happy to review patches!

Cool thanks - leave this with me, I have a working package so can submit
a patch shortly!


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Types and builds for mypy
  2022-10-22 17:05   ` Phil
@ 2022-10-25 23:47     ` Maxim Cournoyer
  0 siblings, 0 replies; 4+ messages in thread
From: Maxim Cournoyer @ 2022-10-25 23:47 UTC (permalink / raw)
  To: Phil; +Cc: guix-devel@gnu.org

Hi Phil,

Phil <phil@beadling.co.uk> writes:

> Thanks for your reply Maxim,
>
> Maxim Cournoyer writes:
>
>
>> Is MyPy the only consumer of Python type annotations?  I think so, but
>> I'm not sure.  If it's the only one, it'd make sense to move mypy and
>> all the annotation types to (gnu packages python-types), I think.
>
> Mypy is certainly a prominent consumer, but you're right - PEP 561 type stub
> packages are also used by PyCharm, pytype, and I've heard CPython can
> use them to compile, to name a few.
>
> So I think my revised opinion is mypy should stay where it is, but I do
> like the idea of keeping all the types in one module?

I'd actually be fine with having mypy in a (gnu packages python-types)
module along its types packages.

[...]

> Cool thanks - leave this with me, I have a working package so can submit
> a patch shortly!

Excellent!

-- 
Thanks,
Maxim


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-10-25 23:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-18 10:09 Types and builds for mypy Philip Beadling
2022-10-22 13:53 ` Maxim Cournoyer
2022-10-22 17:05   ` Phil
2022-10-25 23:47     ` Maxim Cournoyer

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).