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
On Wed, 5 Aug 2020 at 00:12, Oscar Benjamin wrote:
>
> On Tue, 4 Aug 2020 at 23:03, Brett Cannon wrote:
> > On Thu, Jul 30, 2020 at 8:41 AM Wes Turner wrote:
> >>
> >> I confess that I don't even know how to subscribe to all threads of a
> >> discourse.
> >>
> >> - [ ] How to subscribe to all
ail-settings-are-not-respected/396
> talking about problems people have had keeping up with/watching and
> participating in conversations on Discourse -- including Paul Moore and
> Paul Ganssle, whose opinions I really want to hear from here. I believe
> I've heard Dan Ryan say that he finds Discou
On Wed, 22 Jul 2020 at 19:31, David Mathog wrote:
> but that shebang has to be corrected when the installation is moved to a
> normal
> environment, which my code is doing now.)
Moving files that are installed by Python packaging tools isn't
supported. It might work, and you can probably make
Awesome! Congratulations on achieving this :-)
Paul
On Fri, 3 Jul 2020 at 16:26, 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
On Sat, 27 Jun 2020 at 01:37, David Mathog wrote:
>
> Thanks for that feedback. Looks like RECORD is the one to use.
>
> The names of the directories ending in dist-info seem to be uniformly:
>
> package-version.dist_info
Note that if you're doing something like this, you should probably
read
On Thu, 25 Jun 2020 at 00:06, David Mathog wrote:
>
> Thanks for the link. Unfortunately there was not a reference to a
> completed package that actually did this. As in, I really do not want
> to reinvent the wheel. Ugh, sorry, that's a pun in this context.
I think the key message here is
On Wed, 24 Jun 2020 at 00:00, David Mathog wrote:
> Does such a beast exist? If so, please point me to it!
Basically no, or at least not to my knowledge. The mechanisms exist,
in the form of import hooks and similar, to build something like this,
but it's not proved to be a common enough
On Sun, 21 Jun 2020 at 21:49, wrote:
>
> PEP 508 allows for pointing to required packages using URL's. This is the
> except:
>
> A minimal URL based lookup::
>
> pip @
> https://github.com/pypa/pip/archive/1.3.1.zip#sha1=da9234ee9982d4bbb3c72346a6de940a148ea686
>
> However, there is
Yay! Congratulations to all involved, and in particular to Dan for
making it happen :-)
Paul
On Thu, 28 May 2020 at 16:10, Sumana Harihareswara wrote:
>
> And pipenv 2020.5.28 is now out: https://pypi.org/project/pipenv/
>
> This roadmap and contribution process issue
>
with the
testing to get access to the latest changes that have been made.
Thanks to everyone who has contributed to this release, and in
particular to all of the people who have tested and provided feedback
on the new resolver so far!
On behalf of the pip maintainers,
Paul Moore
--
Distutils-SIG mailing
It's already available as a separate package:
https://pypi.org/project/resolvelib/
Paul
On Tue, 24 Mar 2020 at 18:52, Brett Cannon wrote:
>
> I couldn't find this in the blog post but is the plan to make the resolver a
> separate package so other tools can use it? Or is the plan perhaps to get
Correct. The installer technology used for the python.org builds
changed some time ago (I think Python 3.4 was the last version to use
an MSI installer).
Paul
On Mon, 9 Sep 2019 at 15:25, Renegad3 Kay wrote:
>
> Greetings!
>
> my organization uses Python across it's departments but the recent
On Sat, 24 Aug 2019 at 06:46, Phil Thompson wrote:
>
> I have a PEP 517 compatible backend which works with pip to install from
> an sdist (via an internal wheel). However there are a couple of
> issues...
>
> pip swallows all output from the backend. Is there anyway for the user
> to see the
On Tue, 20 Aug 2019 at 14:50, Brian Skinn wrote:
> I wonder if there's an OS dependence here, though -- I'm almost certain I've
> had to use `--only-binary` in the past, to avoid pip on my Windows machines
> trying to download and build sdists, even when wheels were available.
Pip prefers
A couple of quick points:
* You want to focus on setuptools rather than distutils. Setuptools
extends distutils with recent packaging developments, distutils is
essentially just core Python legacy support these days.
* Wheels (built binaries) are typically tagged as manylinux using the
auditwheel
One thought - is it possible in github to subscribe to "everything
that isn't closed"? I couldn't see such an issue but that would (a)
let me ignore the lockbot messages, and (b) let me ignore close
threads so I wouldn't even need lockbot.
Paul
On Sun, 2 Jun 2019 at 12:26, Paul Mo
The bot has just been enabled, and it's catching up on historical bugs
(which can't be done all in one go, as rate limits would hit us).
Hopefully it should die down in a few days.
Whether there's a way to tell github not to send such notifications,
or whether it's possible for us to configure
On Sun, 26 May 2019 at 13:59, Bernat Gabor wrote:
>
> 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.
To be more specific, the "setuptools setup.py install" command will be
supported for as
On Wed, 20 Feb 2019 at 16:44, Steve Dower wrote:
>
> On 20Feb2019 0839, Paul Moore wrote:
> > On Wed, 20 Feb 2019 at 16:28, Steve Dower wrote:
> >>
> >> To be totally clear, and maybe this needs to be in the PEP (probably in
> >> three more various forms
On Wed, 20 Feb 2019 at 16:28, Steve Dower wrote:
>
> To be totally clear, and maybe this needs to be in the PEP (probably in
> three more various forms to make sure everyone gets it), you can emulate
> most of the PEP today with "pip install --target __pypackages__/3.7 ..."
> and "$env:PYTHONPATH
On Tue, 12 Feb 2019 at 16:28, Eric Peterson
wrote:
>
> Brilliant, that's exactly what I was looking for—both the simple API and json
> API look very useful. Thanks!
Just a quick note, the simple API is required for every index server
to support, whereas the JSON API is not (yet?) standardised
On Thu, 31 Jan 2019 at 09:07, Jan Musílek wrote:
> Sure, I'll get to it.
Just seen your summary. Very nice, thanks! If any questions arise as a
result that you would like me to chip in on, feel free to ping me on
the issue.
Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To
On Tue, 29 Jan 2019 at 15:49, Jan Musílek wrote:
>
> Thank you all for very helpful comments!
Thank you for bringing this up.
> I've carefully considered everything you said and I'm now mostly convinced,
> that PEP 508 actually doesn't need to be expanded to include version
> specifiers.
On Tue, 29 Jan 2019 at 15:07, Thomas Kluyver wrote:
>
> On Tue, Jan 29, 2019, at 2:43 PM, Paul Moore wrote:
> > And when they start adding
> > version numbers to that (like the OP's package >= 10.0 @
> > https://github.com/owner/package.git) I can't even begin to und
On Tue, 29 Jan 2019 at 14:23, Donald Stufft wrote:
> However, one thing we *could* maybe do is allow including a specific version.
> So instead of treating the URL as the version you would provide the name,
> version, and url. So you’d have something like "foo-1.0 @
>
On Tue, 29 Jan 2019 at 13:16, Nick Coghlan wrote:
>
> On Tue, 29 Jan 2019 at 20:09, Paul Moore wrote:
> > OK, I think that it may well be in that case that URL specifiers don't
> > satisfy that specific use case that dependency_links did[1]. But URL
> > specifiers we
On Tue, 29 Jan 2019 at 09:51, Jan Musílek wrote:
> Well, yes, that's basically it. I don't think that there is anything wrong
> with PEP 508 pointing only at specific versions. BUT, it's widely proposed as
> replacement for dependency links, which it's clearly not because of this
> issue.
OK,
On Tue, 29 Jan 2019 at 09:20, Tzu-ping Chung wrote:
>
> I’m wondering, why is it needed to specify both a version and a link? I
> assume the version specifier would be redundant when a link is provided as
> the source, since the link can only point to one possible package version.
From what I
On Sun, 27 Jan 2019 at 21:02, Thomas Kluyver wrote:
>
> On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote:
> > What is more difficult is the question of whether the PEP should
> > change. As Chris pointed out, the previous discussion ended up saying
> > that th
On Sun, 27 Jan 2019 at 14:39, Thomas Kluyver wrote:
> 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.
I'm not entirely sure what you're intending when you refer to a
"proper PEP 517 build
On Mon, 3 Dec 2018 at 15:30, Nick Coghlan wrote:
>
> On Mon, 3 Dec 2018 at 23:11, Paul Moore wrote:
> >
> > On Mon, 3 Dec 2018 at 12:16, Nick Coghlan wrote:
> > > P.S. Paul asked how we can have manylinux tags without updating PEP
> > > 425 to include the
On Mon, 3 Dec 2018 at 12:16, Nick Coghlan wrote:
> P.S. Paul asked how we can have manylinux tags without updating PEP
> 425 to include them, and the answer is that the actual compatibility
> tag spec is at
> https://packaging.python.org/specifications/platform-compatibility-tags/
> and that
On Sat, 1 Dec 2018 at 04:42, Nathaniel Smith wrote:
> How does this affect spec-writing? Well, we want to allow for non-pip
> installers, so the part that pip does has to be specified. But pip's
> part is really straightforward.
[...]
> So the proposal here is to refactor the spec to match how
On Fri, 30 Nov 2018 at 08:12, Nathaniel Smith wrote:
>
> Hi all,
>
> The manylinux1 -> manylinux2010 transition has turned out to be very
> difficult. Timeline so far:
>
> March 2017: CentOS 5 went EOL
> April 2018: PEP 517 accepted
> May 2018: support for manylinux2010 lands in warehouse
>
On Fri, 30 Nov 2018 at 09:22, Pradyun Gedam wrote:
>
>
> On Fri, 30 Nov 2018 at 1:42 PM, Nathaniel Smith wrote:
>>
>> April 2018: PEP 517 accepted
>
>
> I think you got the wrong PEP number.
Should be 571, presumably?
Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe
On Sat, 3 Nov 2018 at 01:27, Donald Stufft wrote:
>
> Just an FYI, I’m going to ask the discuss.python.org admins to add a
> Packaging category to that discourse instance for the discussion of packaging
> in Python, basically as a sister discussion location to distutils-sig. I plan
> to
tandardizing -- do you want libraries and
> applications managed by the same workflow, or not. Is that not a
> conversation that we want to have? If not, what conversation topics are we
> allowed to address in this discussion?
>
>
> Dan Ryan
> gh: @techalchemy // e: d...@danry
On Sun, 30 Sep 2018 at 22:17, Chris Jerdonek wrote:
>
> In reading this discussion, I feel like a cool picture would be a Venn
> diagram of several of the common tools out there, with dots (or some
> other type of regions) to represent the various use cases they do or
> don't support.
Yeah, that
On Sun, 30 Sep 2018 at 20:50, Tzu-ping Chung wrote:
>
>
> > On 01/10, 2018, at 00:47, Dan Ryan wrote:
> >
> >> Uses Pipfile as a project marker instead of pyproject.toml.
> >
> > See above. pyproject.toml wasn't standardized yet when pipenv was released
> > (and still isn't, beyond that it is
On Sun, 30 Sep 2018 at 13:26, Chris Jerdonek wrote:
> It can be challenging to get stuff like
> this working if the tools you're using make too many directory or
> workflow assumptions. However, a very powerful or flexible tool (e.g.
> Git), or a collection of several tools that each does one
On Sun, 30 Sep 2018 at 11:48, Nathaniel Smith wrote:
>
> Now that the basic wheels/pip/PyPI infrastructure is mostly
> functional, there's been a lot of interest in improving higher-level
> project workflow.
[...]
> This is very much a draft, intended as a seed for discussion, not a
>
On Wed, 26 Sep 2018 at 15:31, Donald Stufft wrote:
>
>
>
> On Sep 26, 2018, at 10:23 AM, Paul Moore wrote:
>
> On Wed, 26 Sep 2018 at 15:11, Paul Ganssle wrote:
>
>
> Sorry it's taken me a while to respond in this thread, but I think I'd
> like to slightly
On Wed, 26 Sep 2018 at 15:11, Paul Ganssle wrote:
>
> 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,
On Tue, 25 Sep 2018 at 22:09, Dan Ryan wrote:
> To Chris’ broader point it is definitely duplicated effort and I am in full
> agreement which is why I want to establish which code should be extracted and
> generalized and where it should be maintained. But as Paul mentioned there
> also is no
On Tue, 25 Sep 2018 at 12:53, Chris Jerdonek wrote:
>
> On Tue, Sep 25, 2018 at 3:47 AM, Tzu-ping Chung wrote:
> > We are using pip internals for things pip wasn’t implemented for.
> > Specifically,
> > Pipenv uses pip’s package-fetching functions to implement its
> > platform-agnostic
> >
On Tue, 25 Sep 2018 at 10:46, Chris Jerdonek wrote:
>
> On Tue, Sep 25, 2018 at 1:25 AM, Tzu-ping Chung wrote:
> > Pipenv wraps pip usages inside a virtual environment, so pip is always
> > available via “pipenv run pip”,
> > so in a sense Pipenv “supports” everything pip does. But as far as
On Mon, 24 Sep 2018 at 23:03, Dan Ryan wrote:
>
> The App/Library point is partly why we haven’t jumped on this bandwagon, the
> distinction is important and keeping things separate has been done
> intentionally. Others (such as Nick or Donald) would be in a better position
> to speak to this
On Mon, 24 Sep 2018 at 16:32, Bernat Gabor wrote:
>
> 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
On Fri, 21 Sep 2018 at 14:09, Tzu-ping Chung wrote:
> On the other hand, there are many other application dependency management
> tools out there, and as far as I know none of them actually have a lock file
> format with interoperability. JavaScript, for example, has maybe the most
>
On Fri, 21 Sep 2018 at 11:41, Nick Coghlan wrote:
>
> On Fri, 21 Sep 2018 at 05:47, Donald Stufft wrote:
> > On Sep 20, 2018, at 3:35 PM, Paul Moore wrote:
> > I don't think anyone's even spoken to the pip maintainers (yet?) about
> > supporting the pipfile format
>
On Thu, 20 Sep 2018 at 19:52, Michael Merickel wrote:
>
> I think it's far-fetched to start thinking pip is legacy. Pipfile has had a
> goal from day 1 to be a format that pip would support. PEP 582 is a path
> forward here for providing a default location for a virtualenv [2] - it's
> just
On Thu, 20 Sep 2018 at 14:25, Donald Stufft wrote:
>
> We don’t typically bother to make big announcements on distutils-sig for
> maintainers of projects, however I’m making an exception in this case because
> of the recent threads on virtualenv maintenance. The current core team of
>
On Thu, 20 Sep 2018 at 08:01, Tzu-ping Chung wrote:
> I’m afraid the new implementation will still need to deal with compatibility
> issues.
> Users expect Pipenv to work exactly as pip, and get very angry if it does not,
> especially when they see it is under the PyPA organisation on GitHub.
On Wed, 19 Sep 2018 at 18:52, Donald Stufft wrote:
>
> On Sep 19, 2018, at 1:14 PM, Tzu-ping Chung wrote:
>
> I feel the plan is quite solid. This however leaves us (who want a Python
> implementation and interface to do what pip does) in an interesting place. So
> I can tell there are a
On Wed, 19 Sep 2018 at 11:34, Tzu-ping Chung wrote:
>
> I have the same experience with Pipenv as Nick’s. I would also guess
> another reason is the lack of knowledge—this is certainly my own before
> I get involved in Pipenv. There is barely any guide on how I should
> implement such a thing,
On Wed, 19 Sep 2018 at 10:54, Nick Coghlan wrote:
> Given that, and assuming Vinay is amenable to the idea, it would be
> nice to revisit the concept of the two layer architecture, with
> packaging as the lower level minimalist strictly standards compliant
> layer, and distlib as the higher level
On Wed, 19 Sep 2018 at 00:52, Dan Ryan wrote:
>
> > so the people benefiting
> > are those who want a supported API for that functionality, and it
> > seems only reasonable to expect them to do the job of moving the code,
> > rather than expecting the pip developers to do so.
>
> This is where I
Agreed. Furthermore, if people are of the opinion that pip's
implementation is suitable, copying it out into packaging is likely
not going to be at all controversial. Of course, it's not going to be
any direct advantage to pip if that's done (we get the same
functionality, just in a different
On Tue, 18 Sep 2018 at 19:54, Thomas Kluyver wrote:
>
> On Fri, Sep 14, 2018, at 4:26 PM, Paul Moore wrote:
> > I don't think it's "hard to predict". I *do* think it's badly
> > documented/not standardised.
> > ...
> > Better would be to have a supp
On Tue, 18 Sep 2018 at 13:45, Olivier Grisel wrote:
>
> > I would say there's value in having two official manylinux flavors at once,
> > for example manylinux2010 for maximum compatibility (it's already 8 years
> > old as far as requirements go!) and manylinux2016 for recent systems
> >
On Mon, 17 Sep 2018 at 17:08, Antoine Pitrou wrote:
>
> Paul Moore wrote:
> > I'm not really familiar with manylinux1, but I'd be concerned if we
> > started getting bug reports on pip because we installed a library that
> > claimed to be manylinux1 and was failing bec
On Mon, 17 Sep 2018 at 16:48, Trishank Kuppusamy
wrote:
>
> On Mon, Sep 17, 2018 at 11:37 AM Antoine Pitrou wrote:
>>
>>
>> Sorry, there was a misunderstanding. Maybe I should have been clearer.
>> My question was about publishing deliberately incompatible manylinux1 wheels
>> (without changing
On Sun, 16 Sep 2018 at 15:08, Nick Coghlan wrote:
> So if folks are still interested in the general idea of improving virtualenv
> and venv interoperability, then my last message to that thread and Paul's
> follow up would be a decent place to start:
>
On Sat, 15 Sep 2018 at 08:26, Jeroen Demeyer wrote:
>
> On 2018-09-14 18:36, Paul Moore wrote:
> > And actually,
> > https://packaging.python.org/guides/distributing-packages-using-setuptools/#data-files
> > is a reasonably clear explanation of the current behaviou
On Fri, 14 Sep 2018 at 17:05, Jeroen Demeyer wrote:
>
> On 2018-09-14 16:39, Paul Moore wrote:
> > My understanding (and I'm not an expert here, so hopefully someone
> > else will confirm or correct) is that yes, the data directory is
> > installed to "
On Fri, 14 Sep 2018 at 16:03, Daniel Holth wrote:
>
> It can be hard to predict where data went at runtime.
I don't think it's "hard to predict". I *do* think it's badly
documented/not standardised. See my previous note - pip installs into
the install_data location that setuptools/distutils
On Fri, 14 Sep 2018 at 12:43, Jeroen Demeyer wrote:
>
> On 2018-09-14 12:55, Alex Grönholm wrote:
> > I'm curious: what data does it attempt to install and where? Have you
> > created a ticket for this somewhere?
>
> The OP mentioned absolute paths. However, it really sounds like a bad
> idea to
On Fri, 14 Sep 2018 at 08:16, Alex Becker wrote:
> Is there a way around this behavior? Am I crazy to even try to install into a
> different virtualenv? Or do I have to re-architect my code to call pip in the
> target virtualenv (which may require me forcing pip to be installed,
> depending on
On Wed, 12 Sep 2018 at 18:33, Nathaniel Smith wrote:
>
> On Wed, Sep 12, 2018, 09:53 sashk wrote:
>>
>> Hi,
>>
>> With latest version of pip, it now forces to build wheel for every package,
>> which causes incompatibilities (due to use of data_files and copying into
>> not standard path) .
On Mon, 10 Sep 2018 at 13:12, Melvyn Sopacua wrote:
>
> > You say "a project (not a library)". I presume by that you mean
> > something like the application building process I described above?
>
> Ok, so there's the first confusion. My use of project is fostered first and
> foremost by django's
On Mon, 10 Sep 2018 at 10:13, Melvyn Sopacua wrote:
> First post, so short introduction:
Hi, and welcome.
> I'm mostly working on Django projects, currently for 3yourminD in Berlin.
> Working with python / Django for 6 going on 7 years. Also experienced in PHP,
> some Js and build systems like
On Sat, 8 Sep 2018 at 04:36, Brett Cannon wrote:
> - activate_this.py (which provides critical inline activation for us when
>> people invoke "pipenv run" from the command line)
>>
> It might make sense to try and add an 'activate' command to venv, e.g.
> 'python -m venv --activate .venv' as a
On Tue, 4 Sep 2018 at 11:28, Nathaniel Smith wrote:
>
> On Tue, Sep 4, 2018 at 3:10 AM, Paul Moore wrote:
> > There's very much an 80-20 question here, we need to avoid letting the
> > needs of the 20% of projects with unusual needs, complicate usage for
> > the 80%. On t
On Tue, 4 Sep 2018 at 08:07, Ronald Oussoren via Distutils-SIG
wrote:
> On 4 Sep 2018, at 01:51, Nick Coghlan wrote:
> On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, wrote:
>>
>> What’s the problem with including GPU and non-GPU variants of code in a
>> binary wheel other than the size of the
On Fri, 31 Aug 2018 at 09:41, Paul Moore wrote:
> My comment about wildcarding is basically a forlorn hope that if we
> can't be sure what we're getting, maybe the best we can do is say
> "well, py3-*-* sounds like it might work, and there's nothing better,
> so let's give it
On Fri, 31 Aug 2018 at 22:03, Brett Cannon wrote:
> You can make your pure Python wheel have a py3-cp36m-* wheel name and you get
> the version specification you want; there is nothing saying a wheel must have
> extension modules if it specifies an ABI tag.
Currently, that won't work, as pip
On Fri, 31 Aug 2018 at 07:15, Nathaniel Smith wrote:
>
> On Thu, Aug 30, 2018 at 6:52 PM, Brett Cannon wrote:
> >
> >
> > On Thu, 30 Aug 2018 at 11:21 Nathaniel Smith wrote:
> >> * Make the 3 tag categories totally independent. Compute a separate set
> >> for each, and then take the full cross
On Thu, 30 Aug 2018 at 19:30, Donald Stufft wrote:
> I find it helpful to generally not think of compatibility tags as hard “this
> wheel is supported on this platform”, but more along the lines of “if I built
> a wheel in the specified environment, I would get the same results”. Those
>
On Tue, 28 Aug 2018 at 07:56, Nick Coghlan wrote:
>
> On Mon., 20 Aug. 2018, 11:54 pm Paul Moore, wrote:
>>
>> My assumption is that the intent is that *all* strings, whether
>> arguments or return values, must be Unicode.
>
> Handling bytes paths correctly cross-
On Tue, 21 Aug 2018 at 12:04, Tzu-ping Chung wrote:
>
> Hi,
>
> Dan and I had been doing most of the maintenance work for Pipenv recently,
> and as Dan mentioned,
> we have been working on some related projects that poke into pip internals
> significantly, so I feel I
> should voice some
On Mon, 20 Aug 2018 at 18:54, Thomas Kluyver wrote:
>
> On Mon, Aug 20, 2018, at 2:52 PM, Paul Moore wrote:
> > The various hooks take directory paths as arguments, and typically
> > return a filename (e.g., build_wheel). The returned filename is always
> > explicitly n
I'm in the process of implementing PEP 517 for pip, and I've hit a
question. I'm pretty sure I know the answer, but I want to be clear,
as whatever the answer is will require some fixing up.
The various hooks take directory paths as arguments, and typically
return a filename (e.g., build_wheel).
On Mon, 20 Aug 2018 at 13:21, Wes Turner wrote:
>
> Something as simple as reading a requirements.txt file into JSON must either
> reimplement or wrongly import from pip._internal.
Or copy pip's code and maintain it locally...
> Anyways,
> Tool authors reimplementing in particular the
On Mon, 20 Aug 2018 at 12:25, Wes Turner wrote:
>
> On Monday, August 20, 2018, Paul Moore wrote:
>> I know "security by obscurity" doesn't work, but I'm happier if
>> details of this library *aren't* widely known - it's not something I'd
>> want to encourage
On Mon, 20 Aug 2018 at 10:54, Wes Turner wrote:
>
> What stable API would be worth maintaining in pip for others to use?
That's probably the sort of question that can only be usefully
answered by projects like pipenv identifying the functionality they
need and proposing something. Which is of
On Tue, 7 Aug 2018 at 02:26, Chris Barker via Distutils-SIG
wrote:
>
> I'm updating some instructions for my students, in which the first thing I do
> is have them run ensurepip:
>
> $ python3 -m ensurepip --upgrade
>
> which resulted in:
>
> $ python3 -m ensurepip --upgrade
> Looking in links:
On Sat, 4 Aug 2018 at 13:31, Jeroen Demeyer wrote:
>
> On 2018-08-04 14:02, Thomas Kluyver wrote:
> > On Sat, Aug 4, 2018, at 9:34 AM, Paul Moore wrote:
> >> Whether timestamps are
> >> preserved by the wheel building process depends on the build system -
> >&
On Sat, 4 Aug 2018 at 12:25, Jeroen Demeyer wrote:
>
> On 2018-08-04 13:16, Paul Moore wrote:
> > Can you give a
> > specific example of an end to end process where the packaging
> > toolchain's current behaviour gives demonstrably the wrong result?
>
> Yes I c
On Sat, 4 Aug 2018 at 10:05, Jeroen Demeyer wrote:
>
> On 2018-08-04 10:34, Paul Moore wrote:
> > Jeroen seemed to say he agreed with this, but
> > I'm not sure I see how that matches his stated requirement for
> > installs to not preserve timestamps...
>
> The
On Sat, 4 Aug 2018 at 09:18, Chris Jerdonek wrote:
>
> On Sat, Aug 4, 2018 at 1:08 AM, Paul Moore wrote:
> > On Sat, 4 Aug 2018 at 08:35, Jeroen Demeyer wrote:
> >
> >> So both are different issues, and I agree with both: during the source
> >> extraction and
On 30 July 2018 at 23:01, David Cournapeau wrote:
> Hi,
>
> I see that there is almost no mention of private packages index in the
> packaging guide, and no recommendation on what to use.
>
> Currently googling for private packages mostly return obsolete (and not very
> practical) recommendations
When you say "not working", you'll need to provide more details. But I
suspect what you're getting is network errors, because PyPI no longer
supports TLSv1 connections, and Python 2.7 for Windows only gained
TLSv2 support in a later release of 2.7 than the one you have. So you
may have problems if
Yay! Congratulations on the release, and thanks for all the work you
put into it.
Paul
On 22 July 2018 at 11:51, Pradyun Gedam wrote:
> On behalf of the PyPA, I am pleased to announce that pip 18.0 has just
> been released.
>
> To install pip 18.0, you can run
>
> python -m pip install
On 21 July 2018 at 01:15, Nathaniel Smith wrote:
> On Fri, Jul 20, 2018 at 5:01 PM, Brett Cannon wrote:
>> I have updated PEP 518:
>> https://github.com/python/peps/commit/af73627e587c25b9ac6f28a0fda01953252df391#diff-f068c801ccb40fad40c0436ff1e25e3f
>
> LGTM. Thanks Brett!
LGTM also. Thanks!
On 19 July 2018 at 11:02, Bernat Gabor wrote:
> 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
On 19 July 2018 at 07:44, Pradyun Gedam wrote:
>
>
> On Tue, 17 Jul 2018, 20:44 Donald Stufft, wrote:
>>
>>
>> On Jul 17, 2018, at 5:27 AM, Paul Moore wrote:
>>
>> There's also a PR cost, in that projects who have enthusiastically
>> adopted pyproje
p36.cp37` as the python implementation tag but this feels a bit
> hackish.
>
> Here are some unresolved questions from the old distutils-sig thread,
> quoting Paul Moore:
>
>> 2. How should tools determine which ABIs a given Python supports?
>> (This is the get_supported
On 17 July 2018 at 08:45, Pradyun Gedam wrote:
>
> On Tue, 17 Jul 2018, 09:11 Brett Cannon, wrote:
>>
>> My point is I don't think enough pieces are in place to force everyone
>> over to --no-isolation to get by if they don't set up pyproject.toml as
>> you're suggesting they be required to. IOW
On 16 July 2018 at 15:56, Pradyun Gedam wrote:
>
> On Mon, 16 Jul 2018, 20:16 Brett Cannon, wrote:
>>
>> I will update the PEP and add you as a reviewer, Paul (might not get to it
>> until Friday, though).
>>
>> On Mon, Jul 16, 2018, 02:23 Paul M
1 - 100 of 1365 matches
Mail list logo
