The only interface for the backend (setuptools) talking with the frontend
(pip) is https://www.python.org/dev/peps/pep-0517/#build-backend-interface.
The PEP itself is the documentation. Lack of documentation on how to fully
automate backend parts it's up to the backend. distutils is deprecated
Hello,
You want to raise the issue directly at the pip issue tracker,
https://github.com/pypa/pip. This mailing list is reserved mostly for
general packaging related topics.
Thanks,
On Mon, Nov 30, 2020 at 6:47 PM Mikhail Golubev via Distutils-SIG <
distutils-sig@python.org> wrote:
> Hi there!
I think it's natural that people on the mailing list will favour the
mailing list over Discourse, just as when asked this question on Discourse
voted for the forum over the mailing list. Taking a more practical look at
the issue, I want to note that 99% of the discussion about packaging and
its
Please vote (and share your thoughts) on how you think virtualenv should
handle what pip you get by default on new virtual environment creation:
https://discuss.python.org/t/how-should-virtualenv-behave-respective-of-seed-packages-e-g-pip-by-default/4146
Thanks,
Bernat
--
Distutils-SIG mailing
With the caveat that one should not use setuptools to satisfy those
dependencies, but instead use some kind of test runner such as tox/nox
(which then delegate to pip to acquire packages).
On Mon, Mar 9, 2020 at 11:10 AM Xavier Fernandez
wrote:
> Hello,
>
> you might want to use the "test"
More information available at
https://discuss.python.org/t/virtualenv-20-0-0-beta1-is-available/3077
--
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
I'll be okay in chiming in on twine All the best Thea!
On Fri, Jul 19, 2019, 23:38 Dustin Ingram wrote:
> Sorry to see you go, Thea! You've done a great job.
>
> I'd be happy to help maintain both these projects.
>
> On Fri, Jul 19, 2019 at 5:33 PM Thea Flowers via Distutils-SIG <
>
It will exist only as a legacy thing, and as setuptools build system
configuration. PEP-517 and PEP-518 defines what pip will support going
forward.
On Sun, May 26, 2019, 15:25 Stuart Axon via Distutils-SIG <
distutils-sig@python.org> wrote:
> I'm making a python package for something python
I'm not sure I agree that setting up a private repository is that hard.
Devpi does an excellent job for open source stuff, or otherwise if you use
Artifactory inside your company that also has similar plugin.
On Tue, Jan 29, 2019 at 1:30 PM Jan Musílek wrote:
> Nick Coghlan wrote:
> > So URL
It feels to me that importing from setup.py level is a code smell and
should be avoided (I mean what happens if you move the source into src
layout, do you now want tools to also append the src folder additionally if
exists?). Can't people just inject at the start of setup.py into sys path
the cwd
nteresting to grow
>>> and experiment with
>>>
>>> but whats really missing is a setuptools conributor with more than just
>>> thinly stretched time.
>>>
>>> -- Ronny
>>> Am 24.09.18 um 17:30 schrieb Bernat Gabor:
>>>
>>&g
I'm aware this might be a controversial subject, so let's have the initial
discussion about it here first for full disclosure and see what people
think about it. Should setuptools support pyproject.toml as configuration
source or not (alternative to setup.cfg which it already does -
decided to extend an invitation of a commit bit to Bernat Gabor, and I’m
> happy to say that he has graciously accepted, and is now part of the team.
> For those unaware, Bernat is currently a developer for the tox project,
> which is one of the major consumers of virtualenv which made him a g
So as a conclusion to this, I think we can say everyone agrees
virtualenv should have some maintenance for a next few years at least.
Sorin and I offered to help with this, can we get some PyPa people
help with this (e.g. give rights on repo) ?
Thanks!
> It should probably be noted that the
I'm maintainer of tox and tox is heavily relying on virtualenv. I would be
up for being a co maintainer, but for now I don't have availability for
heavy undertakings. I've had a discussion with Donald at Pycon us about it
and there certainly is a desire and place for virtualenv. the issue is
Fair enough :+1: Let's go ahead with this then.
> For tools (such as pip) where 2a and 2b behave differently, yes it would. But
> that's a pip implementation decision which can be made independently of the
> resolution of this discussion (the PEP allows either behaviour). The details
> of
Sorry to bump into this so late, but:
Would not 2a be more backward compatible than 2b? I mean people may
have build environments/installs doing:
- pip install setuptools-scm setuptools pbr
- pip install os-system-level
This way you can bypass the setup requires of setuptools to use
In the pep it's stated tools can use the tool section
https://www.python.org/dev/peps/pep-0518/#id28 and at no point says build
tools only. So I don't think at all strange that towncrier uses it. It
follows the words of the pep quite rigourously.
On Thu, Jun 28, 2018, 18:40 Thomas Kluyver wrote:
I don't consider building from source a niche use case per se, given that
pip is most widely adopted PEP-517/518 build frontend. What other build
frontends there are or are to be recommended for usage (with
setuptools/flint/poetry being mostly backends)?
On Thu, Jun 28, 2018 at 8:35 AM Paul Moore
Hello,
I would vote for option 2, again in the spirit of explicit better than
implicit (as maintainer of tox). pip should raise an error I think and fail
the build.
That being said, we don't want to start breaking existing packages. So what
about doing a release of pip that raises a warning
20 matches
Mail list logo
