Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove Lib/plat-*/* files #72214

Closed
zware opened this issue Sep 8, 2016 · 30 comments
Closed

Remove Lib/plat-*/* files #72214

zware opened this issue Sep 8, 2016 · 30 comments
Assignees
@doko42

Comments

@zware
Copy link
Member

zware commented Sep 8, 2016

BPO 28027
Nosy @gvanrossum, @doko42, @vstinner, @ned-deily, @xdegaye, @zware, @koobs

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/doko42'
closed_at = <Date 2017-10-01.02:13:44.001>
created_at = <Date 2016-09-08.18:38:19.070>
labels = []
title = 'Remove Lib/plat-*/* files'
updated_at = <Date 2017-10-02.09:52:51.344>
user = 'https://github.com/zware'

bugs.python.org fields:

activity = <Date 2017-10-02.09:52:51.344>
actor = 'vstinner'
assignee = 'doko'
closed = True
closed_date = <Date 2017-10-01.02:13:44.001>
closer = 'zach.ware'
components = []
creation = <Date 2016-09-08.18:38:19.070>
creator = 'zach.ware'
dependencies = []
files = []
hgrepos = []
issue_num = 28027
keywords = []
message_count = 30.0
messages = ['275106', '275107', '275108', '275110', '275121', '275189', '275252', '275253', '275435', '275443', '275444', '275449', '275450', '275451', '275454', '275455', '275456', '275457', '275465', '275466', '275468', '275469', '275482', '275494', '275514', '275515', '275517', '275537', '303445', '303520']
nosy_count = 8.0
nosy_names = ['gvanrossum', 'doko', 'vstinner', 'ned.deily', 'xdegaye', 'python-dev', 'zach.ware', 'koobs']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue28027'
versions = ['Python 3.6']
@zware
Copy link
Member Author

zware commented Sep 8, 2016

After discussion at the core dev sprints, Guido has decreed that the files in Lib/plat-* can and should be removed.

@zware zware self-assigned this Sep 8, 2016
@python-dev
Copy link
Mannequin

python-dev mannequin commented Sep 8, 2016

New changeset 14d89359a389 by Zachary Ware in branch 'default':
Issue bpo-28027: Remove Lib/plat-* files
https://hg.python.org/cpython/rev/14d89359a389

@zware
Copy link
Member Author

zware commented Sep 8, 2016

Will close this after the buildbots have confirmed they don't hate it.

@python-dev
Copy link
Mannequin

python-dev mannequin commented Sep 8, 2016

New changeset e256583e6062 by Zachary Ware in branch 'default':
Issue bpo-28027: Mention the names of the removed modules in Misc/NEWS
https://hg.python.org/cpython/rev/e256583e6062

@vstinner
Copy link
Member

vstinner commented Sep 8, 2016

Issue bpo-28027: Mention the names of the removed modules in Misc/NEWS

Thanks :-)

@zware
Copy link
Member Author

zware commented Sep 8, 2016

None of the buildbots have complained about this (they've been too busy complaining about other things), so I'm closing it.

@zware zware closed this as completed Sep 8, 2016
@vstinner
Copy link
Member

vstinner commented Sep 9, 2016

Yeah! Thanks Zach :-)

@koobs
Copy link

koobs commented Sep 9, 2016

YES, finally. Thanks :)

@vstinner
Copy link
Member

vstinner commented Sep 9, 2016

FYI I first proposed to remove plat-* in 2011:
https://mail.python.org/pipermail/python-dev/2011-October/114105.html

That's why I added os.RTDL_* constants:
https://docs.python.org/dev/library/os.html#os.RTLD_LAZY

@doko42
Copy link
Member

doko42 commented Sep 9, 2016

the removal of these modules should follow the normal deprecation process, for 3.6, then be removed for 3.7. There is no harm for this approach.

@doko42 doko42 reopened this Sep 9, 2016
@gvanrossum
Copy link
Member

Why? Do you have a dependency on these? None of them are documented.
Do you propose to document them just so we can mark them deprecated?

@doko42
Copy link
Member

doko42 commented Sep 9, 2016

Since the 3.6 cycle, these modules are regenerated for the build, so they are not outdated anymore. They are not a maintenance burden either. So I'd like to see these available in 3.6, and documented as deprecated. Then removed in 3.7.

Apparently the proposers for this removal don't have the time for an analysis before the beta, I don't have the time either. So pretty please let's revert that change, and instead have the deprecation documented.

@gvanrossum
Copy link
Member

No, you need to demonstrate that they are used (despite undocumented).

On Fri, Sep 9, 2016 at 2:26 PM, Matthias Klose <report@bugs.python.org> wrote:

Matthias Klose added the comment:

Since the 3.6 cycle, these modules are regenerated for the build, so they are not outdated anymore. They are not a maintenance burden either. So I'd like to see these available in 3.6, and documented as deprecated. Then removed in 3.7.

Apparently the proposers for this removal don't have the time for an analysis before the beta, I don't have the time either. So pretty please let's revert that change, and instead have the deprecation documented.

----------

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue28027\>

@zware
Copy link
Member Author

zware commented Sep 9, 2016

I have been searching sources.debian.net, and have found no evidence of anything that would be broken by this. Every use of these modules that I have found has been already wrapped in try/except ImportError, or is in code that is fairly obviously not meant for Python 3.

@doko42
Copy link
Member

doko42 commented Sep 9, 2016

whatever you searched, there are regressions:

https://codesearch.debian.net/search?q=import+DLFCN

some of these have conditional imports, however even boost uses unconditional imports, and is often used as an embedded copy.

@zware
Copy link
Member Author

zware commented Sep 9, 2016

Those boost imports will never be triggered in Python 3, because sys.platform will never be 'linux2'.

@vstinner
Copy link
Member

vstinner commented Sep 9, 2016

https://codesearch.debian.net/search?q=import+DLFCN

I see 8 projects: boost, trilinos, vtk6, openbabel, gdcm, paraview, ecasound, yade. It doesn't like a giant project to update them.

boost1.58_1.58.0+dfsg-5.1/libs/mpi/build/init.py

import sys
if sys.platform == 'linux2':
import DLFCN as dl

It's not like this code already works on Python 3 :-) sys.platform was replace with "linux" on Python 3.

It's easy to replace this import with:

try:
import DLFCN as dl
except ImportError
import os as dl

@doko42
Copy link
Member

doko42 commented Sep 9, 2016

these projects are the ones packaged by Debian; there are surely others. Now again, why can't the actual removal for 3.7, following the usual deprecation rules?

@zware
Copy link
Member Author

zware commented Sep 9, 2016

Because in every release of Python they have been undocumented, in any recent release of Python they have been inaccurate (at best) and probably unnecessary, they have been unmaintained for years, the presence of the plat-* dir on sys.path slows down imports from any directory after it on sys.path, the problem they purport to solve has other much better solutions, and this discussion started 5 years ago with only the the slightest of defenses from MvL.

@xdegaye
Copy link
Mannequin

xdegaye mannequin commented Sep 9, 2016

Since the 3.6 cycle, these modules are regenerated for the build, so they are not outdated anymore. They are not a maintenance burden either.

Indeed, they are regenerated by the changes made in bpo-23968 ("rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)"). And they are a maintenance burden as these changes fail to regenerate these modules on Android cross-builds as explained in msg269360, the generation being done with the headers of the build system instead of the target host (Android) system. The problem is not limited to Android cross-compilation of course.

@vstinner
Copy link
Member

vstinner commented Sep 9, 2016

The FreeBSD packager told me that he is *very* happy to see these modules go away, it was also a pain for him to maintain a patch for them. The maintaince burden is even wider than Python source code.

@zware
Copy link
Member Author

zware commented Sep 9, 2016

With no solid evidence against the change and much joy with the change, I'm reclosing the issue. doko, if people complain to you about being broken by this, feel free to refer them to me.

@zware zware closed this as completed Sep 9, 2016
@doko42
Copy link
Member

doko42 commented Sep 9, 2016

you asked for evidence, you got evidence. re-opening the issue again. feel free to close it again without any evidence, and stating that you ignore the usual deprecation rules.

@doko42 doko42 reopened this Sep 9, 2016
@vstinner
Copy link
Member

vstinner commented Sep 9, 2016

Matthias Klose: Maybe you didn't understand something: breaking the backward compatibility was a deliberate choice. It's a matter of maintenance burden versus the number of broken applications.

According to your search, there are only 8 projects in the wild which will break on Python 3.6. Please compare this number to the number of Python modules on PyPI: 88 298 packages, according to https://pypi.python.org/pypi

Moreover, it seems like some of these 8 projects are not compatible with Python 3 yet, so it's not like this specific change broke them...

Finally, I don't like repeating myself, but: fixing these project requires to modify A SINGLE LINE OF CODE. I know well that Debian likes patching packages, it's not like it is something technically impossible.

Please don't reopen the issue again without a very strong argument.

@vstinner vstinner closed this as completed Sep 9, 2016
@doko42
Copy link
Member

doko42 commented Sep 10, 2016

"It's a matter of maintenance burden". No I don't think so.

As agreed on IRC with zware, I'll restore the removed modules, including a deprecation notice.

@doko42 doko42 reopened this Sep 10, 2016
@doko42 doko42 assigned doko42 and unassigned zware Sep 10, 2016
@zware
Copy link
Member Author

zware commented Sep 10, 2016

"Agreed" is a bit strong, I still don't agree that the change was bad or should be reverted. I'm just not ruling out the possibility of a partial (because there is absolutely no reason to re-add the files for any platform but Linux and *maybe* OSX) reversion if you put forth the effort to do it after bpo-28046 and add deprecation notice.

@vstinner
Copy link
Member

Sorry, I'm leaving this discussion now.

@gvanrossum
Copy link
Member

The modules should remain deleted for 3.6b1 so we can see if there are
actually any complaints -- if we get any we can consider restoring
them for b2. I fail to be convinced by the arguments against deletion
brought up so far -- the "evidence" produced is way too thin to
matter.

@zware
Copy link
Member Author

zware commented Oct 1, 2017

Since we've reached 3.6.3 with no complaints that have made it to me, I'm going to go ahead and close the issue.

@zware zware closed this as completed Oct 1, 2017
@vstinner
Copy link
Member

vstinner commented Oct 2, 2017

Thank you Zachary for this removal ;-)

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@doko42 doko42

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@vstinner @koobs @gvanrossum @zware @doko42