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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
