[issue32387] Disallow untagged C extension import on major platforms

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I think it'd be worth doing on POSIX systems for some 3.8 alpha/beta release 
cycles before making a final call there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Brett Cannon]

Brett Cannon  added the comment:

It's 3.8 time now. :) Should we try and resolve this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Ned Deily]

Ned Deily  added the comment:

As far as I know, it has not been discussed elsewhere and I think the potential 
for breaking third-party distributions is too high to risk making this change 
this late in the release cycle, independent of Steve's concerns in msg308878.  
Unless someone can dispel those concerns prior to the imminent 3.7.0b3 ABI 
freeze, I think this should be deferred to 3.8.

--
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Brett Cannon]

Brett Cannon  added the comment:

Not sure if this has missed the 3.7 train, but bumping this to check if the 
discussion on distutils-sig ever occurred and what the  result of it was. 
(Otherwise the PR just needs a news entry and it should be ready.)

--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Stefan Behnel]

Change by Stefan Behnel :


--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Interesting use case Josh.  I don't know of a good way to deal with 
non-extension-module Python API using .so files.  I like your extension hack, 
but what is the problem with having the version embedded in the .so name?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Josh Rosenberg]

Josh Rosenberg  added the comment:

So, just for clarity, is there another approved mechanism for distributing an 
extension that just happens to act as a (Python version specific) C support 
library? I've wanted to be able to build a library (static or dynamic) that is 
installed to lib/pythonX.Y/site-packages so it can be found by other extensions 
that use it without them having to ship a copy themselves.

The best solution I found was building and installing untagged extensions with 
pip; the extension features weren't actually used for anything but unittesting 
the library, but making it an extension meant it got installed to the Python 
version specific site-packages.

If untagged extensions aren't just old-fashioned, but banned, my use case is 
broken, and I've been completely unable to find a decent, non-Cython based, 
setup.py based pattern for building a C library that provides wrappers for 
Python API calls (and therefore must target specific Python versions).

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Christian Heimes]

Christian Heimes  added the comment:

+1

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Gregory P. Smith]

Gregory P. Smith  added the comment:

did this get discussed on distutils-sig?  It's a trivial change (for the POSIX 
only PR) and would be neat to go through one of the 3.7 beta cycles to see if 
anything serious an unexpected is likely to come up for anyone.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Ned Deily]

Ned Deily  added the comment:

With my macOS hat on, I don't see a problem with doing this.  C extensions 
built via Distutils have been version-tagged on macOS since 3.5.0 (for some 
reason, macOS was skipped when PEP 3149 was originally implemented).

With my release manager hat on, it sounds like a good idea.  But it could 
introduce a compatibility problem for anyone who doesn't use Distutils to 
produce extension modules.  So I'd like to see this proposal get a little more 
visibility, at the minimum, bringing it up on the Distutils SIG mailing list.  
We should also ensure that the change gets mentioned in the 3.7 What's New 
document.  And somewhere in the docset there should be some documentation for 
the .so file name requirements.  AFAICT, today it's really not mentioned 
anywhere in the docs other than the reference to PEP 3149 in the 3.2 What's 
New.  Until the packaging documents for extension modules get overhauled 
perhaps something could be added to the Building chapter of the Extending and 
Embedding document:
https://docs.python.org/3/extending/building.html#building-c-and-c-extensions

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the heads-up Steve.

> Considering a .pyd file linking against pythonXY.dll is only going to load in 
> the context of that version anyway, this is hardly urgent.

I see.  That's a good argument for keeping the current extensions list, then.  
We can narrow the change to POSIX platforms.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Steve Dower]

Steve Dower  added the comment:

Please don't rush this in, at least for Windows. I deliberately decided to keep 
the included pyd files untagged for a reason, and need to recall what that was. 
(It might be in the issue when we added the tags.)

Considering a .pyd file linking against pythonXY.dll is only going to load in 
the context of that version anyway, this is hardly urgent. There is also no 
supported tag on Windows for building against the stable ABI, so that would 
have to be added and enabled in the various build tools.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Decorater]

Decorater  added the comment:

Attached is my changes to the vcxproj files based on an field already in 
python.props.

--
Added file: https://bugs.python.org/file47342/changes.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Decorater]

Decorater  added the comment:

If needed I could help upload the updated project files here for this issue.

--
nosy: +Decorater

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Antoine Pitrou  added the comment:

cc'ing people for the pip/PyPI aspects of this.

--
nosy: +Marcus.Smith, dstufft

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Also, even if they are common, it seems reasonable that pip could be trained to 
rename untagged binaries on install after doing something to determine if they 
should be compatible with >=3.7 or not.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Gregory P. Smith]

Gregory P. Smith  added the comment:

+1 on doing this.

It might also be worth examining all of the latest package version wheels on 
pypi to see which packages claiming to support Python 3 have binary wheels 
containing untagged .pyd or .so files.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Antoine Pitrou  added the comment:

If I'm understanding correctly, the ".pyd" extension is hardcoded in the 
various ".vcxproj" files.  Which means this PR would need the help of a Windows 
expert to progress forward :-S

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Actually, let me correct this: the build fails on Windows (see AppVeyor).  
That's because the Windows build process, for some reason, produces untagged 
pyd files.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Interestingly, the test suite doesn't seem affected at all.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +njs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

Change by Antoine Pitrou :


--
keywords: +patch
pull_requests: +4835
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32387] Disallow untagged C extension import on major platforms

[Antoine Pitrou]

New submission from Antoine Pitrou :

Windows and the major POSIX platforms (including Linux and macOS) now support 
loading C extension with a version-tagged name (and build them likewise), such 
as "foobar.cpython-36.so".

Following the discussion in 
https://mail.python.org/pipermail/python-dev/2017-December/151328.html, I 
propose to remove the ability to load untagged C extension names on those 
platforms.  IOW, "foobar.dll" or "foobar.so" will not be recognized when 
"import foobar" is executed anymore.

--
components: Interpreter Core
messages: 308741
nosy: brett.cannon, eric.snow, ncoghlan, ned.deily, paul.moore, pitrou, 
ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Disallow untagged C extension import on major platforms
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com