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...@pyth
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.
--
e 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 unsubscribe
tension 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.org
https:
e 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/distutils-sig@p
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.python.org/
Message archived a
those 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
?
--
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/message
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@python.org
To unsubs
t 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.org
https://mail.python.org/mm3/mailman3/lists/di
7YMMDQR/
> Yay! That worked. Thanks very much 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
ned for sunsetting this redirect?
--
Joni Orponen
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
age
managers.
--
Joni Orponen
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Mon, Feb 5, 2018 at 10:01 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 6 February 2018 at 00:35, Joni Orponen <j.orpo...@4teamwork.ch> wrote:
> > On Mon, Feb 5, 2018 at 2:51 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> >>
> >> As an ill
espan. As discussed, 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
___
to get by, but it is one more layer to
keep track of.
--
Joni Orponen
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
be reasonable to finally Withdraw PEP 426
> (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 on
sewhere, where it would have a higher impact.
>
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
