thought
end users and/or CI infrastructures of organisations keep and update their
local copies and thus only disclose the fact they're using such a database?
-- Joni Orponen
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...
ough being a tad lucky through archive.org - pre-stdlib
inclusion elementtree eggs are a fine example of this).
http://www.buildout.org/en/latest/reference.html#buildout-configuration-options
The real solution is to dive in to maintain the package barely enough to
upload a new release to PyPI, though.
--
rceive on my coworkers/peers/collaborators as well as myself.
>
See the changelog on 2.10.0. There was an extension for that before, and
now that's handled via setuptools.
https://pypi.org/project/zc.buildout/
--
Joni Orponen
--
Distutils-SIG mailing list -- distutils-sig@python.org
To u
th extension types.
>
Buildout shares this problem. PIL is a classic example of an egg, which can
have vastly different runtime based on the compile time.
--
Joni Orponen
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.
g of people working on?
--
Joni Orponen
--
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/distu
the end users of the wheel.
Oddly enough this seems to be by far the least problematic on Windows.
--
Joni Orponen
--
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.
se available on GCC <= 4.2.0 as per PEP 513?
--
Joni Orponen
--
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
) way?
--
Joni Orponen
--
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/me
there could be actual interest
in any gains.
There's pre-existing speculation from the GCC list in regards to
performance from a while back, but that discussion went nowhere:
https://gcc.gnu.org/ml/gcc-help/2011-03/msg00330.html
--
Joni Orponen
--
Distutils-SIG mailing list -- distutils-sig@
I'm providing this purely for reference as it predates warehouse and the
current infrastructure: Is such trickery still required with warehouse and
the new infrastructure?
--
Joni Orponen
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python
uch for this, Mark - it'll be a major
> usability improvement for me, at least.
>
This is something I've wanted in most mailing lists for over a decade now.
Thank you very much.
Did this break the existing mail archive links now, though?
--
Joni Orponen
___
On Mon, Apr 16, 2018 at 7:27 PM, Laura Hampton
wrote:
> Monday April 30 (2018-04-30): We plan to shut down legacy PyPI
> https://legacy.pypi.org . The address pypi.python.org will continue to
> redirect to Warehouse.
>
Is there a timeline planned for sunsetting this redirect?
--
On Wed, Feb 28, 2018 at 10:30 PM, Victor Porton wrote:
> How to deal with the files to be placed into /etc or a similar dir?
>
Provide example / template files and document the intended deployment
strategy for people who will deploy this software / distribution package
managers.
--
On Mon, Feb 5, 2018 at 10:01 PM, Nick Coghlan wrote:
> On 6 February 2018 at 00:35, Joni Orponen wrote:
> > On Mon, Feb 5, 2018 at 2:51 PM, Nick Coghlan wrote:
> >>
> >> As an illustrative example, manylinux1 was essentially manylinux2007,
> >> and it&#
the year does not ultimately mean all that much.
Just going with sequential version numbers exposes and/or hides just enough
for the end user.
Is there a particular reason for not picking RHEL 7 as the base for
manylinux2 at this point?
--
Joni Orponen
__
layer to
keep track of.
--
Joni Orponen
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
; (rather than continuing to defer it), and have PEP 566 define metadata
> version 2.1, so that it's unambiguously the latest metadata version.
>
Jump straight to 3.0 to clear out any confusion and/or ambiguity on the
next backwards-incompatible one?
--
Joni Orponen
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
pact.
>
All that said, +1 for not bothering with it.
If it ever is tackled, I'm sure this day and age will bring more, more
visible and more direct feedback on it working or not working for users
than the previous iteration.
--
Joni Orponen
_
18 matches
Mail list logo
