[Distutils] Re: Unsubscribing from this list

[Paul Ganssle]

Another possible middle ground between shuttering the list entirely and
maintaining the spam would be (if possible) to close the list to new
membership, but keep the existing list in place for the purpose of
announcing important changes and things that need community input on the
discourse.

On 9/21/20 9:50 AM, Thomas Kluyver wrote:
> If it's not already the case, could someone configure the list so that only 
> subscribers can send messages?
>
> If we've already got any obvious anti-spam measures like that in place, then 
> I'm starting to agree that the signal to noise ratio has fallen too low. Of 
> the 10 latest conversations in the archive, 5 are spam, 2 are people 
> announcing that they're leaving the list, 2 real questions getting no 
> discussion, and 1 FYI about a discussion happening on Discourse.
>
> Thomas
>
> On Mon, 21 Sep 2020, at 14:33, Paul Moore wrote:
>> I'm going to unsubscribe from this list, as it appears to be getting
>> little but spam any more. I'll still be available on the Packaging
>> topic on Discourse (https://discuss.python.org/c/packaging/14).
>>
>> To be honest, I think it's time to discontinue this list. But that's
>> for others to decide.
>>
>> Paul
>> --
>> Distutils-SIG mailing list -- distutils-sig@python.org
>> To unsubscribe send an email to distutils-sig-le...@python.org
>> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/distutils-sig@python.org/message/J66LYNCZKNJTJYRIAS63225Y5XJZK2CM/
>>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/DP7EXNLZ2GRKCSIAGCSFZWMPBD24NAUX/



signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/4AI4XHDSYMBSIV2WF3PQDPR5DSMAGIFH/

[Distutils] Re: Setuptools adopts distutils

[Paul Ganssle]

I don't think setuptools actually /does/ rely on the distutils from the
standard library.

One of the first things setuptools does is replace the distutils module
in sys.modules with setuptools._distutils
.
Anywhere else in the codebase that you see any variation on import
distutils, you /should/ get code exclusively from setuptools._distutils.

I believe we're disconnecting from distutils and replacing it. I think
we should be able to deprecate distutils in Python 3.10. I don't think
there's ever been explicit agreement on this point, but my understanding
is that we're planning on moving everything from the distutils namespace
into setuptools (and we're in the very long and drawn-out process of a
massive widdling-down of the functions setuptools / distutils provides,
so you can rest assured we'll be deprecating the pointless stuff).

Best,
Paul

On 7/13/20 9:57 AM, Matthias Klose wrote:
> On 7/3/20 5:18 PM, Jason R. Coombs wrote:
>> I’m pleased to announce the release of Setuptools 48, which adopts the 
>> distutils codebase from CPython per 
>> pypa/setuptools#417 and 
>> pypa/packaging-problems#127.
>>
>> Given the amount of change this effort involved, it’s likely unstable and 
>> thus the major version bump. Please report issues at the Setuptools issue 
>> tracker. I’ll be around today (IRC, Gitter, Slack) to either disable the 
>> functionality or add an escape hatch if needed.
> Thanks for doing that!
>
> At the Python language summit in 2018, I proposed to deprecate and maybe 
> remove
> distutils from CPython. When looking at setuptools 49.3, I see that
> setuptools/_distutils still relies on distutils as distributed in CPython. Is
> this really wanted?  I see distutils / setuptools mostly as a build time tool,
> which doesn't have to be installed at runtime, that's why you have a separate
> binary package in Debian/Ubuntu, called python3-setuptools.
>
> Examples for unexpected / creative usages, which are unrelated to building a
> package are:
>
>  - distutils.version
>Used “everywhere”, moved back to the python package in Debian/Ubuntu.
>This maybe should be replaced by using distlib.version.
>
>  - distutils.spawn: find_executable
>Replace with shutil.which, this can definitely go, because there's
>a replacement in the Python3 standard library, and starting with
>48.x, setuptools only targets Python3.
>
>  - distutils.util: strtobool
>Rewrite, no equivalent in the stdlib?
>
>  - distutils.sysconfig:
>Mostly replaced by sysconfig
>
> Maybe I'm missing something, but as I currently see setuptools it has to 
> follow
> CPython's ongoing changes in distutils, without an option to deprecate 
> distutils
> any time soon, and it still provides things which from my point of view, it
> shouldn't provide.
>
> Matthias
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/NXR4ZWO23FWDAN65ZFOPORLHU44ARS2V/


signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/45DAK4HPPQ4KYDIH2CZT3NC3H5BTKGXZ/

[Distutils] PyCon US 2020 Packaging Summit: Registration and Topic Proposal

[Paul Ganssle]

/Cross-posting this announcement to both distutils-SIG and discourse.
The main discussion thread should be on the discourse
./

Greetings one and all,

Though each of us cuts our own path through the harrowing jungle that is
the days of our lives, we are all inevitably drawn closer and closer to
a single fate; yes, of course I am talking about PyCon 2020’s Packaging
Summit! April is looming on the horizon, threatening to take us
unawares, but we are a crafty sort, and have prepared to meet its ambush
with a secret weapon: DILIGENT PREPARATION AND SPREADSHEETS!

In my last announcement, I asked that you save the date: *Thursday,
April 16, 2020*, but provided you no other action items. I am now coming
to you with TWO actions that you can take. /If you don’t know what the
packaging summit is, please see the website for more details
./

 1. *Register*! This year we will be collecting registration ahead of
time, and like the Language Summit we will be curating the list of
attendees to try and maximize the effectiveness of the limited time
we have for these discussions. In addition to people actually
working on packaging tools, we’re also looking to see people with
many different perspectives participating in the discussions, so if
you are on the fence as to whether or not you qualify but you’re
interested in participating, please register.

You can register at http://bit.ly/python-packaging-summit-2020-reg

Registration is open /now/ and we will close the registration form on
*March 7th, 2020*. All registration decisions should be finished by
*March 15th, 2020*.

 2. *Propose topic for discussion*! In previous years, topics were
proposed in the room or ahead of time on discourse. This year, we’ll
be collecting discussion topics with something closer to a private
Call for Proposals, and then releasing all the discussion topics for
public voting at the same time. We’ll be doing it this way to
prevent biasing certain selections based on their position in the
voting list or length of time available to be voted on.

Topic suggestions will be evaluated independent of the submitter; please
propose any topic you would like to see discussed — you don’t have to be
the driver of an idea to propose it. We will schedule about 5 minutes at
the beginning of each discussion period for someone to give a quick
introduction to the topic. By default the person (or people) who
proposed the topic will be responsible for either giving that
introduction or delegating the task to someone else, but if one of your
proposals was selected and you cannot present or find someone to
present, the organizers will find someone to give the introduction.

You may find the topic proposal form at
http://bit.ly/python-packaging-summit-2020-topics

Topic proposal is open /now/ and will close on *March 7th, 2020*. Topic
voting is expected to run from March 9th - March 30th.

This and other information is available at our website:
https://us.pycon.org/2020/hatchery/packaging/

If you have any questions or concerns, feel free to respond on the
discourse

or to contact me or one of the other organizers.

--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/JN74XDWGVSN75652AGGAWCDXWEZPWTAG/

[Distutils] Packaging Summit 2020: Save the Date!

[Paul Ganssle]

Greetings one and all!

Each year millions of eyes around the world eagerly wait at their
computer with baited breath to learn the timing of the most fabulous,
extravagant, decadent and hyperbolically oversold event of the year: The
Python Packaging Summit. While most of the details aren't finalized (and
in fact basically no details are finalized), in the interest of giving
those who would like to attend a chance at some additional notice on
their travel plans, we have established that the date of the summit:
*Thursday, 16 April 2020* (the day before the first PyCon talk day).

For the past two years we've unofficially held our mini-summit on the
first day of PyCon Sprints, but given that this summit is of particular
interest to maintainers - many of whom would like to spend the first day
of sprints actually sprinting - we have decided to run the summit on the
tutorials day parallel to the Education Summit. We have applied for a
spot in the Hatchery program, but even if we are not accepted as an
official PyCon evenat, we will make arrangements to run the summit
off-site on that day.

For those unaware of the nature of the summit, you may want to pay
attention to the "hyperbolically oversold" portion of my description
less than the "decadent" and "extravagant" portions. The purpose of the
summit is to get a bunch of people interested in Python Packaging
together to discuss and coordinate on important topics in packaging and
how we can move them forward. If you are on the fence about joining and
want to know more, here are some detailed notes taken at the summit last
year:
https://docs.google.com/document/d/1Wz2-ECkicJgAmQDxMFivWmU2ZunKvPZ2UfQ59zDGj7g/edit#heading=h.7rw2gk16okic

As I mentioned earlier, we have finalized essentially *no* details of
this summit other than the date. I do not know how many people will be
able to attend or by what mechanism we will prioritize attendance at the
summit if there is limited space.

In the coming months please keep an eye out for:

  * Registration details (if such a thing is deemed necessary)
  * A call for topic suggestions
  * Voting on how to prioritize topic suggestions

Looking forward to seeing you all there!
Paul



signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/ZEZNY2MCUN3S3JGUFF6U6OWVEOKW2UAF/

[Distutils] Re: setup.py test deprecation timeline

[Paul Ganssle]

I would say that there is no specific timeline, I would urge everyone to
do it sooner rather than later, because even though we haven't *removed*
it, we're also mostly not fixing it if it's broken in some way (unless
it gets improved incidentally due to general codebase improvements). One
prominent example of this is that at least as of somewhat recently,
`test_requires` dependencies were installed with `easy_install`, which
has many problems - one of which is that it doesn't respect
`python_requires`. That will become increasingly important in a
post-Python 2 world, and even if we don't actively remove `setup.py
test`, you may be broken unexpectedly at any time.

As for timeline, my guess is we won't do it earlier than around October
2020, since we only started emitting the warnings in October 2019. That
is by no means a hard deadline - if it becomes a burden to maintain it
or if we find some flaw that makes us decide that it's doing more harm
than good, we'll probably remove it before then.

Best of luck with the migrations, thanks for your efforts!

Best,
Paul

On 1/14/20 7:15 PM, b...@eff.org wrote:
> Is there an ETA for when setuptools is going to break the test subcommand? It 
> would be useful for me to know how long I have to stop using tests_require 
> and to help OS package maintainers migrate to a new way of running tests.
>
> Thanks for any info!
>
> Brad Warren
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/LCONSYDYRLKXVMQI5XAPZOJ6X2RJU6U3/



signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/H6EB2Q6SPOC3DIQTRV5EIHBXNKGRHTON/

[Distutils] Re: Trouble combining namespace packages and package_dir option in setup

[Paul Ganssle]

I've replied on this setuptools issue
,
you should be able to fix this by switching to pip install.

The core issue is that setup.py install is installing a `.egg` called
"namespace.foo" *directly into site-packages*

$ ls venv/lib/python3.7/site-packages/
easy-install.pth  namespace.foo-0.0.1-py3.7.egg  pip-19.1.dist-info 
__pycache__  setuptools-41.0.1.dist-info  wheel-0.33.1.dist-info
easy_install.py   pip    pkg_resources  
setuptools   wheel

While pip correctly installs the "namespace" folder with a "foo" module
under it:

$ ls venv/lib/python3.7/site-packages/
easy_install.py  namespace.foo-0.0.1.dist-info  pip-19.1.dist-info 
__pycache__  setuptools-41.0.1.dist-info  wheel-0.33.1.dist-info
namespace    pip    pkg_resources  
setuptools   wheel

Best,
Paul

On 5/1/19 10:24 AM, Alex Adamson wrote:
>
> Hello,
>
> I'm trying to create a package that has a namespace package inside a
> directory |src| below the root directory of the project. I was trying
> to follow the instructions laid out in the documentation here
> ,
> but could not get the example described there to work using setuptools
> 41.0.0:
>
> [adamson@home] {build-test-37} ~/test-pkg$ tree --charset unicode .
> .
> |-- setup.py
> `-- src
> `-- namespace
> `-- mypackage
> |-- __init__.py
> `-- mod1.py
>
> 3 directories, 3 files
>
> [adamson@home] {build-test-37} ~/test-pkg$ cat setup.py 
> from setuptools import setup, find_namespace_packages
>
> setup(name="namespace.mypackage",
>   version="0.1",
>   package_dir={'': 'src'},
>   packages=find_namespace_packages(where='src'))
>
> [adamson@home] {build-test-37} ~/test-pkg$ conda list -e
> # This file may be used to create an environment using:
> # $ conda create --name  --file 
> # platform: linux-64
> ca-certificates=2019.1.23=0
> certifi=2019.3.9=py37_0
> libedit=3.1.20181209=hc058e9b_0
> libffi=3.2.1=hd88cf55_4
> libgcc-ng=8.2.0=hdf63c60_1
> libstdcxx-ng=8.2.0=hdf63c60_1
> ncurses=6.1=he6710b0_1
> openssl=1.0.2r=h7b6447c_0
> pip=19.1=py37_0
> python=3.7.0=h6e4f718_3
> readline=7.0=h7b6447c_5
> setuptools=41.0.0=py37_0
> sqlite=3.28.0=h7b6447c_0
> tk=8.6.8=hbc83047_0
> wheel=0.33.1=py37_0
> xz=5.2.4=h14c3975_4
> zlib=1.2.11=h7b6447c_3
>
> [adamson@home] {build-test-37} ~/test-pkg$ python setup.py install --record 
> files.txt
> running install
> running bdist_egg
> running egg_info
> creating src/namespace.mypackage.egg-info
> writing src/namespace.mypackage.egg-info/PKG-INFO
> writing dependency_links to 
> src/namespace.mypackage.egg-info/dependency_links.txt
> writing top-level names to src/namespace.mypackage.egg-info/top_level.txt
> writing manifest file 'src/namespace.mypackage.egg-info/SOURCES.txt'
> package init file 'src/namespace/__init__.py' not found (or not a regular 
> file)
> reading manifest file 'src/namespace.mypackage.egg-info/SOURCES.txt'
> writing manifest file 'src/namespace.mypackage.egg-info/SOURCES.txt'
> installing library code to build/bdist.linux-x86_64/egg
> running install_lib
> running build_py
> creating build
> creating build/lib
> creating build/lib/namespace
> creating build/lib/namespace/mypackage
> copying src/namespace/mypackage/mod1.py -> build/lib/namespace/mypackage
> copying src/namespace/mypackage/__init__.py -> build/lib/namespace/mypackage
> creating build/bdist.linux-x86_64
> creating build/bdist.linux-x86_64/egg
> creating build/bdist.linux-x86_64/egg/namespace
> creating build/bdist.linux-x86_64/egg/namespace/mypackage
> copying build/lib/namespace/mypackage/mod1.py -> 
> build/bdist.linux-x86_64/egg/namespace/mypackage
> copying build/lib/namespace/mypackage/__init__.py -> 
> build/bdist.linux-x86_64/egg/namespace/mypackage
> byte-compiling build/bdist.linux-x86_64/egg/namespace/mypackage/mod1.py to 
> mod1.cpython-37.pyc
> byte-compiling build/bdist.linux-x86_64/egg/namespace/mypackage/__init__.py 
> to __init__.cpython-37.pyc
> creating build/bdist.linux-x86_64/egg/EGG-INFO
> copying src/namespace.mypackage.egg-info/PKG-INFO -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying src/namespace.mypackage.egg-info/SOURCES.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying src/namespace.mypackage.egg-info/dependency_links.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> copying src/namespace.mypackage.egg-info/top_level.txt -> 
> build/bdist.linux-x86_64/egg/EGG-INFO
> zip_safe flag not set; analyzing archive contents...
> creating dist
> creating 'dist/namespace.mypackage-0.1-py3.7.egg' and adding 
> 'build/bdist.linux-x86_64/egg' to it
> removing 'build/bdist.linux-x86_64/egg' (and everything under it)
> Processing namespace.mypackage-0.1-py3.7.egg
> Copying namespace.mypackage-0.1-py3.7.egg to 
> /nas/dft/ire/adamson/.conda/envs/build-test-37/lib/python3.7/site-packages
> Adding namespace.mypackage 

[Distutils] Re: PEP 517 - source dir and sys.path

[Paul Ganssle]

On 1/29/19 7:46 AM, David Shawley wrote:

> I agree with pip's view that the presence of pyproject.toml means that
> you are
> *explicitly* announcing compliance with PEP-517.  The unexpected part
> was that
> the setuptools build-system shim was incomplete.  This will be addressed
> shortly if Paul Ganssle has anything to do with it (thanks Paul!).


Thanks for the shout out, and I really do appreciate the recognition,
but I would like to clarify that if anything I have /delayed/ getting
this fixed with my insistence that the semantics should be different
between setuptools.build_meta and setup.py. I think there are already
some useful features of this distinction, but it's certainly true that
if we had simply modified the path in the existing build backend, this
would be fixed now (with the release of the latest setuptools) instead
of necessitating a new pip release.

Anyway, even if I was right to insist on this distinction, I don't want
to take the credit for fixing this when a lot of people put in a lot of
effort discussing this and working out the right path forward, which is
very tough in packaging, where people want many new and useful features,
but they're also weary of all the churn in their build and deployment
system.

That said, I hope this doesn't sound like I'm complaining that you
complimented my work. I would hate to make you think that someone could
be bothered by the fact that you thanked an open source maintainer.

Best,
Paul



signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/RIRR4UP3DT6XUVQWS64BGF27PQJM4MBA/

[Distutils] PEP 517 Backend boostrapping

[Paul Ganssle]

Bundled up in the confusion about the PEP 517 rollout is the issue that
PEP 517 does not allow for PEP 517 backends to use PEP 517 to build
themselves, and how the bootstrapping should take place is left unspecified.

This is a problem for setuptools at the moment, and presumably other
build backends like flit. Since I know not everyone on this list follows
the discourse, I thought it prudent to advertise here that I've created
a thread on the Python discourse to discuss this topic:
https://discuss.python.org/t/pep-517-backend-bootstrapping/789




signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/TA5RJUV5EMATOBMHSQDOTYXL77AIAIIH/

[Distutils] Re: PEP 517 - source dir and sys.path

[Paul Ganssle]

The possibility of doing it in setuptools is discussed extensively in
the threads, but a lot of us are going off of half-remembered
discussions, so it's probably a good idea to get a central "agenda" of
the things we want to resolve and create a new thread for discussion in
the discourse.

Items I see for the agenda:

- The most urgent question for discussion that I see is what should be
done /now/. This seems to me like a major issue, and I'm wondering if it
would make sense to revert the major change in behavior until we iron
out some of the details. It seems like many people in the thread (and
people I've spoken to in person) are "solving" this by just pinning pip
to < 19.0.

- From the setuptools side, I think we don't want to be forced to rush
things. setuptools is already a huge bundle of compromises and
less-than-ideal defaults because we have so few opportunities to fix the
crustier parts of it without introducing enormous code churn. I don't
want us to have to put compatibility shims into our main build backend
just to unbreak some people today if we can avoid it with a less
permanent "band-aid" solution.


On 1/27/19 9:39 AM, Thomas Kluyver wrote:
> I haven't read those discussions in full (sorry to be lazy, but
> there's quite a lot there), but my initial take is that the rule
> doesn't apply to running setup.py scripts, where there's a greater
> need for backward compatibility. I think the rule about the CWD not
> being on sys.path only applies to loading a proper PEP 517 build
> backend when that's specified in pyproject.toml.
>
> Furthermore, if the build backend then wants to run some code with the
> CWD on sys.path, I think it's free to do so, so this could be
> implemented in the setuptools backend. The rule is only for how the
> frontend loads the backend, not what the backend does afterwards.
>
> Where a real PEP 517 backend needs to be loaded from the CWD (e.g. for
> Flit to bootstrap itself), we've already got the intreehooks package
> to make this possible: https://pypi.org/project/intreehooks/
>
>
>
> On Sun, Jan 27, 2019, at 2:26 PM, Chris Jerdonek wrote:
>> For those of you who participated in the PEP 517 discussion during
>> the summer of 2017 (just prior to its provisional acceptance), I want
>> to flag that one of the issues discussed back then has now resurfaced
>> for discussion. This is because the feature was turned on by default
>> in pip's latest release (19.0) less than a week ago.
>>
>> The issue is the one around whether the source directory should be
>> included in sys.path. The resurfacing is more or less as predicted.
>> For example, in one email [1] from August 29, 2017, Nick summarized
>> the state of things by saying (not too long before provisional
>> acceptance)--
>>
>> So I think we can deem this one resolved in favour of "Frontends
>> must ensure the current directory is *NOT* on sys.path before
>> importing the designated backend", as starting there will mean we
>> maximise our chances of learning something new as part of the
>> initial rollout of the provisionally accepted API.
>>
>>
>> And also--
>>
>> 2. If omitting it is genuinely a problem, we'll likely find out
>> soon enough as part of implementing a setup.py backend
>>
>>
>> Basically, that "soon enough" moment has arrived, and at least one
>> discussion on how to resolve it has started on the tracker here:
>> https://github.com/pypa/pip/issues/6163
>>
>> There is another discussion here, but it's probably better for the
>> discussion to be in one spot:
>> https://github.com/pypa/setuptools/issues/1642
>> Maybe Discourse?
>>
>> --Chris
>>
>> [1]:
>> https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
>>
>> --
>> Distutils-SIG mailing list -- distutils-sig@python.org
>> 
>> To unsubscribe send an email to distutils-sig-le...@python.org
>> 
>> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/distutils-sig@python.org/message/LMGQS2DCMDFMMIYXH3A7ZDZN55P3CFMV/
>
>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/G3FNWBTRUV5E4Z4MWDNOQ2PZTXLLD3XF/


signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/ZGY5HEHQFGJ2FUVACKPUTU3ZZLQFB3RW/

[Distutils] Re: setuptools API compatibility

[Paul Ganssle]

Are you saying this is true of App Engine or of setuptools?

Setuptools is /pretty/ conservative, but I think there's still the
caveat that major versions may have backwards-incompatible changes in
it. For example, version 39.0 removed some symbols
 after
a long deprecation period. Version 38

started requiring ordered sequences for install_requires.

Regarding the "there isn't currently a way for a package to specify
build-time compatibility with a specific version of setuptools", is it
not possible to do this with pyproject.toml?

[build-system]
requires = ["setuptools>38.0", "wheel"]

Doing it this way will work with pip wheel or pip install, though it all
depends on how good the PEP 518 support is for the tools you're using to
build your package.

On 10/11/18 4:12 PM, Dustin Ingram wrote:
> Hi Brian, I work on the team that develops the App Engine Python 3.7
> runtime. You're correct, by default we use the latest versions of
> setuptools, pip and wheel for the runtime. We do this to ensure that
> the runtime is always compatible with the latest features that newly
> created packages may be using.
>
> Since there isn't currently a way for a package to specify build-time
> compatibility with a specific version of setuptools, new versions of
> setuptools are more or less fully backwards-compatible with older
> packages.
>
> That said, there is the potential for a bug in a new version of these
> tools to cause unexpected installation failure. We are able to detect
> issues with new releases of these tools, and if we see such a problem,
> we have the means to pin them back to an older version if necessary
> until the bug is fixed.
>
> Please let me know if you have any other questions!
>
> D.
>
>
> On Fri, Oct 5, 2018 at 6:16 PM  > wrote:
>
> Hi,
>
> Does setuptools make any API stability guarantees i.e. should all
> setup.py files that work with setuptools version X also work with
> setuptools version Y where  Y > X?
>
> I'm asking because the App Engine Python 3.7 runtime keeps it's
> version of setuptools up-to-date and I'm wondering if that is
> problematic due to API compatibility i.e. that package
> installation might fail due to an incompatibility introduced in
> setuptools.
>
> Cheers,
> Brian
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> 
> To unsubscribe send an email to distutils-sig-le...@python.org
> 
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> 
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/6UN6P7UCZVSS3XKM7CVNW7KRLQEYGPUW/
>
>
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/A3X24JNDG2FLM7JBV2MAZEQNXZHBZ2RA/


signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/XA5RMBDNTXIVMBNODYEKLJS2KR7NZ5LG/

[Distutils] Re: setuptools configuration in pyproject.toml

[Paul Ganssle]

Sorry it's taken me a while to respond in this thread, but I think I'd
like to slightly reframe the question away from `setuptools`
specifically - considering that certain requirements are standardized in
the Core Metadata specification, might it make sense to add those to the
core spec for `pyproject.toml`, so that there's a single standard way
for various tools to look for the install dependencies of a project?


This would involve adding something like a `distribution.requires` and
possibly `distribution.requires-python`, which would map more or less
directly to `Requires-Dist` and `Requires-Python`.

Similarly there is an argument for adding the `Provides-` metadata to
this table.

That said, I can think of some reasons not to do this - for example in
some cases you may want to generate the dependencies in some way as part
of the build script (possibly from another format that is more
convenient), which means that even in the most ideal conditions we
couldn't say, "You should *only* be using the [distribution] table to
specify your dependencies".

Best,
Paul


On 9/25/18 3:37 PM, Thomas Kluyver wrote:
> On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote:
>> I personally don't see much advantage in the "dump everything in one
>> file" philosophy. so from a personal POV I'd prefer setuptools' config
>> to remain in setup.cfg, but if they have reasons for wanting to move,
>> the PEP allows them that option.
> I've come across quite a few people who want to avoid 'clutter' in the top 
> level of the repository. By the time you've got packaging config, test 
> config, CI config, editor config and so on, I can see where they're coming 
> from. I think all this mass of different files can also be confusing to 
> newcomers. So I try to avoid creating extra files where it's easy to do so.
>
> But in the case of setuptools, I wouldn't push for it to use pyproject.toml. 
> It will have to continue supporting setup.py and setup.cfg forever, so all 
> you could do is add yet another place that metadata might live, making it 
> more complicated to understand.
>
> Of course, I'm biased, because if setuptools uses pyproject.toml, flit looks 
> kind of redundant. ;-)
>
> Thomas
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/N6SW5IMDROORV7ZZZ3GBMQQAYODOSFAV/



signature.asc
Description: OpenPGP digital signature
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/AFV3HWV742MTQMOZOY26WFSLE7PV24YF/