On Mon, 2010-08-16 at 15:14 -0400, Toshio Kuratomi wrote:
> On Mon, Aug 16, 2010 at 02:03:51PM -0400, David Malcolm wrote:
> > On Fri, 2010-08-13 at 21:57 -0400, Toshio Kuratomi wrote:
> > > > > On Fri, Aug 13, 2010 at 02:20:51PM -0400, David Malcolm wrote:
> > > If this is okay, then I'd modify your point (a) to be this plan:
> > >
> > > When code that turns all warnings into errors is encountered, have it
> > > instead cause PendingDeprecationWarning to print to stderr via
> > > warnings.simplefilter('default', PendingDeprecationWarning)
> >
> > I don't like this approach: it's a divergence from upstream, and it
> > seems like magic: it seems to be second-guessing the API call.
> >
> > It seems simpler and clearer to ask that code that enables errors on
> > warnings need to turn it off for PendingDeprecationWarning to be able to
> > use modules that are known to break in the presence of the
> > PendingDeprecationWarning-treated-as-exceptions.
> >
>
> As long as you're saying turn off 'error' for all
> PendingDeprecationWarnings, not just ones that are known to break,
> I think we're saying the same thing in different words.
>
> Here's how I see it working.
>
> python-foo: Does not touch the warnings filters. No need to modify
> anything.
>
> pyhton-bar: Sets warnings.simplefilter('default'). No need to modify
> anything
>
> pyhon-baz: Sets warnings.simplefilter('errors'). Patch the code to set
> warnings.simplefilter('default', PendingDeprecationWarning) and send a note
> to upstream that 'errors' can cause segfaults in pieces of code unrelated to
> python-baz.
>
> python-qux: Contains code using the old PyCObject API and doesn't catch the
> exception. No need to modify.
>
> The key here, and only place where I'm not sure if we're saying the same
> thing is that setting simplefilter('errors') can break unrelated code. So
> python-baz might not use any code that breaks but python-corge might use
> both python-baz and python-qux which breaks in this combination. So we
> never want that to go through without adding a second filter somewhere. The
> easiest place to track the adding of the second filter is in python-baz,
> right after the filter that sets up 'errors'.
>
>
> > > > > > One issue here is that this API expresses a binary interface between
> > > > > > different Python modules, and that we don't yet have a way to express
> > > > > > this at the rpm metadata level. I think we should, to make it easier to
> > > > > > track these issues in the future. I don't think it's possible to track
> > > > > > these automatically, but we could do it manually.
> > > > > >
> > > > > Tracking this manualy is no good unless you can explain to people how to
> > > > > detect it. Once you can explain how to manually detect it, it might be
> > > > > possible to automatically detect it....
> > > >
> > > > You have to scrape through for ABI calls to PyCObject: the presence of
> > > > the calls are visible in the ELF metadata, but not the exact strings.
> > > > Actually, it _might_ be possible to figure them out via disassembly of
> > > > the machine code, but this seems fragile.
> > > >
> > > This already sounds like something that is too involved for maintainers and
> > > package reviewers to do. I think this might be something that doesn't leave
> > > the drawing board without tooling to at least do part of the detective work.
> >
> > Fundamentally the review process for this involves grepping through the
> > source code; any usage of a PyCObject_* function will return NULL if
> > PendingDeprectationWarning is set to "error". It needs a little ability
> > to read C code, but (I hope) not much. The issue with macros in the
> > header files is a nasty gotcha, though :-(
> >
> What I'm commenting on here is the desire to stick all uses of the PyCapsule
> API into an RPM virtual Provide and Require.
>
> It doesn't seem like something that we can require of packagers and
> reviewers without raising the barrier of entry for their skillset quite
> a bit.
The presence is detectable though (via eu-readelf), so we could have an
rpmlint test for it (detect if a python extension calls PyCapsule_*, if
so, it must have a Requires/Provides on a capsule, though we can't tell
what it will be).
So we could implement the test, but point people needing help to fix it
at #fedora-python (or the python SIG list) where I can help them (and
others).
Having said all this, I'm not at all sure that this metadata would help
solve problems :)
> > I had a go at writing some release notes for this issue here:
> > https://fedoraproject.org/wiki/Features/Python_2.7#Caveat:_PyCObject_and_warnings
> >
> > How does this look?
> >
> Looks good but change:
> - warnings.simplefilter('ignore', PendingDeprecationWarning)
> + warnings.simplefilter('default', PendingDeprecationWarning)
>
> If the coder is going through the trouble of turning warnings into 'error',
> they likely want to be at least warned about PendingDeprecationWarning as
> well.
Thanks; I made the change
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
