On Sun, Aug 14, 2016 at 6:12 PM, Yuya Nishihara <y...@tcha.org> wrote:

> On Sun, 14 Aug 2016 09:52:19 -0700, Gregory Szorc wrote:
> > On Sat, Aug 13, 2016 at 3:15 AM, Yuya Nishihara <y...@tcha.org> wrote:
> > > # HG changeset patch
> > > # User Yuya Nishihara <y...@tcha.org>
> > > # Date 1470969317 -32400
> > > #      Fri Aug 12 11:35:17 2016 +0900
> > > # Node ID e1318b322922baf91a146d92b1ee21cc0e509c04
> > > # Parent  3d8b3e09190aaacc3c57ae37b265838df4accb1a
> > > osutil: switch to placeholder module that imports cpy/pure selectively
> > >
> > > You have to do "make clean" to test this change. Otherwise, the
> existing
> > > osutil.so would be loaded directly. Also, you need "make clean" to go
> back
> > > to previous revisions.
> > >
> > > Nit: should we move osutil.c to mercurial/cpy?
> >
> > I like the spirit of this series to establish some more order around the
> > various module implementations.
> >
> > I'm pretty sure mpm won't like the `make clean` requirement, as he likes
> > the ability to bisect without having to worry about build system foo.
>
> Yeah, I know that would be the most controversial part of this series.
> Good news is you can bisect without "make clean" as long as you have
> mercurial/osutil.so compiled by old revisions. .so appears to precede .py.
>
> > I haven't been paying close attention to the cpy/pure/cffi discussions. I
> > know there is a common pattern in other Python projects of having modules
> > define the pure Python code inline then have code at the bottom of the
> > module/file that imports C extensions/libraries and overwrites the Python
> > bits. So e.g. we could move mercurial/pure/osutil.py to
> mercurial/osutil.py
> > then at the bottom of the file do something like:
> >
> >   if modulepolicy != 'py':
> >       globals().update(policy.uimportvars(u'osutil'))
> >
> > Or we could potentially inline the cffi bits without having to a)
> maintain
> > a separate file/module or b) abstract the import mechanism for modules
> with
> > C implementations. In other words, we could add C implementations to any
> > module without having to tell the module import mechanism about which
> > modules contain C implementations. We would likely still need this
> > policy.importvars() trick for C extensions, since C extensions need to
> live
> > in their own module. But at least we wouldn't have an extra module for
> cffi.
>
> Another idea I came up with is to add a helper to load cffi functions into
> pure. This works only if cffi functions don't depend on pure functions and
> classes.
>
>   # mercurial/pure/osutil.py
>   ...
>   globals().update(policy.importcffioverrides(u'osutil'))
>
> What I want to address right now are:
>
>  a) move cffi codes and compiled objects out of the root directory
>  b) centralize the import rule of cffi, instead of try-except in pure
> modules
>

I think that this series is a stop in the right direction towards making
the cffi integration nicer. We can always work on "unifying" the modules
later.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to