On 11 November 2015 at 16:19, Robert Collins wrote:
> On 11 November 2015 at 18:53, Nick Coghlan wrote:
>> On 11 November 2015 at 08:44, Nathaniel Smith wrote:
>>> On Mon, Nov 9, 2015 at 6:11 PM, Robert Collins
>>> wrote:
>>>> On 10 November 2015 at 15:03
needless complexity
that can just be dropped entirely
Packaging systems are a uniquely difficult ship to steer (even moreso
than programming language design), since interoperability is king, and
you need to cope with legacy versions of both packaging tools *and*
language runtim
ey take up.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 13 November 2015 at 03:08, Brett Cannon wrote:
>
>
> On Wed, 11 Nov 2015 at 04:06 Paul Moore wrote:
>>
>> On 11 November 2015 at 06:35, Nick Coghlan wrote:
>> > Windows Python 2 installations require manual PATH modifications
>> > regardless, but it&
On 13 November 2015 at 22:22, Donald Stufft wrote:
>
>> On Nov 13, 2015, at 2:07 AM, Nick Coghlan wrote:
>>
>> This isn't an urgent question, but rather a "if the stats are readily
>> available, I'm curious as to the answer" one: what
moving them
into the history section), but I don't think reorganising them is at
all urgent, so that can be tackled after this initial rearrangement is
done.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
("example", "w")
>>> os.stat("example").st_ino
242960
>>> os.stat(f.fileno()).st_ino
244985
>>> os.stat(f2.fileno()).st_ino
242960
As Wayne noted, the fact shared libraries can be overwritten while
processes are using them is then just an ar
ons, I think the PEP should
> provide a link to the implementation.
No, it shouldn't, as the whole point of these PEPs is to get away from
implementation defined behaviours. If somebody can't implement their
own library from scratch using just the material in the PEP, then the
PEP i
I'd be surprised if any new tools did, and it's
entirely possible now for tools to become popular while only
supporting git).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
rd, and JSON-LD is indeed interesting, it just doesn't solve any
high priority problems for the Python packaging ecosystem.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
impact other than fixing up a few issues and giving implementations something
> they can point at for what the standard behavior is.
>
> So congratulations to everyone working on this :)
Huzzah! Thanks for working through these details, folks :)
Cheers,
Nick.
--
Nick Coghlan |
nstall" in
existing packaging and deployment scripts and converting them over to
use "pip install" instead, especially since all the *other* command
line flags would continue to be the setuptools flags rather than the
pip ones.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@g
d for
setuptools. Those assessments may well come down on the side of "not
worth the hassle", but the scope of the proposed change still falls a
long way short of being a "maintenance horror".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
e cases, we can then consider how best to factor that code
out into a shared library that pip vendors (perhaps the existing
packaging library used for PEP 440 version specifier support, perhaps
a new library)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
t in that ecosystem
has a lot of similarities to Debian's approach:
http://www.rpm.org/wiki/PackagerDocs/DependenciesOverview#Weakdependencies
Cheers,
Nick.
P.S. I had to check the actual degree of similarity myself, so for
reference, the relevant Debian docs link is at
https://www.debian.org
fresh
environment based on the generated requirements.txt).
I'm not sure it makes as much sense in the case where the thing you're
working on is itself a distributable Python package with its own
setup.py - it seems like you'd end up duplicating information between
setup.py and re
encies when building
for a Python version that wasn't provided by your distro.
If you'd prefer to avoid any configuration and debugging of
C/C++/FORTRAN build processes, then you may prefer to grab miniconda
and download distro-independent pre-built binaries:
http://conda.pydata.org/
quot;use
CentOS 5.11" approach seems promising.
In terms of non-scientific packages, the main group I'd suggest
getting in touch with is pycryptography, as we'll probably want to
baseline a more recent version of OpenSSL than the one in CentOS 5.11.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 14 January 2016 at 20:12, Nick Coghlan wrote:
> On 14 January 2016 at 15:55, Nathaniel Smith wrote:
>> - build some test wheels
>> - write a proper PEP
>> - convince pip and pypi maintainers that this is a good idea ;-)
>
> While I've historically advocated
in PEP 440 around version ordering and how that
relates to version comparison operators that you don't really need to
think about when working at the level of processing a list of
dependency specifiers.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
;ve run out of things to
remove, rather than things to add", I've also been considering the
semantic dependencies idea, and thinking it would be beneficial to
move that out to a proposed extension, while reverting the baseline
metadata to the well established "setup_requires" and
; image and the amazing auditwheel tool linked below, but he asked me to
> do the honors of posting it :-).
Very nice!
Do you have a link to the text file version of that? I can assign it a
number and add it to the PEPs repo.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
to your working copy, that would be great.
In terms of the content, it all looks reasonable to me personally, but
we'll wait and see what everyone else has to say (especially the PyPI
and pip developers).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
On 21 January 2016 at 16:50, Nick Coghlan wrote:
> On 21 January 2016 at 16:39, Robert McGibbon wrote:
>> Hi Nick,
>>
>> The text version is here:
>> https://raw.githubusercontent.com/manylinux/manylinux/master/pep-.rst
>
> Thanks - this is now PEP 513:
>
w to get the external dependencies installed.
If Donald can provide the list of "most downloaded wheel files" for
other platforms, that could also be a useful guide as to how many
source builds may potentially already be avoided through the draft
"manyli
On 21 January 2016 at 20:05, M.-A. Lemburg wrote:
> On 21.01.2016 10:31, Nick Coghlan wrote:
>> On 21 January 2016 at 19:03, M.-A. Lemburg wrote:
>>> By using the version based approach, we'd not run into this
>>> problem and gain a lot more.
>>
>> I
st
as much to other platforms as it does Linux, and even for Linux,
private indices can already be used to host prebuilt Linux binaries).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist -
On 22 January 2016 at 02:53, M.-A. Lemburg wrote:
> On 21.01.2016 17:13, Nathaniel Smith wrote:
>> On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote:
>>>
>>> On 21.01.2016 10:31, Nick Coghlan wrote:
>>>> On 21 January 2016 at 19:03, M.-A. Lemburg
platform here supersede that section
>> of 425?
>
> I guess this is a pure process question, so I'll defer to Nick...
I've finally started working on changing the change proposal process,
so I'm going to say "No" :)
I'll start a separate thread about that,
ts us back to something much
closer to the way CPython uses the PEP process, which should help both
folks trying to figure out the *current* approaches to
interoperability handling, as well as those of us trying to work on
improvements to those standards.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@g
On 22 January 2016 at 17:04, Matthew Brett wrote:
> Hi,
> On Thu, Jan 21, 2016 at 7:45 PM, Robert T. McGibbon
> wrote:
>> On Thu, Jan 21, 2016 at 7:32 PM, Nick Coghlan wrote:
>>> However, it does suggest a possible alternative approach to naming
>>> these c
more specific Linux
versions (as previously discussed in the context of Nate Coraor's
Starforge work)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
re it could be
adopted.
>From the point of view of future-proofing PEP 513 against having such
an alternative available in the future, the main question that would
need to be considered is how tools would decide download priority
between a distro-specific wheel, an integrated linux wheel, and
ylinux2 in the future - scanning popular manylinux wheel downloads
for both embedded libraries and for external dependencies outside the
defined set.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
t;the packaging of this particular package is broken".
However, moving the "generic linux wheels are ignored by default"
behaviour to pip-the-client, rather than enforcing it as a restriction
on PyPI uploads could definitely be a reasonable alternative way of
addressing that
far as the regex defining the permitted content goes,
appropriately caveating PEP 376 to better match the reality of how
current generation tools work is one of my main motivations for
revising the specification process)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aust
few months).
Cheers,
Nick.
[1] https://www.python.org/dev/peps/pep-0011/#microsoft-windows
[2] https://wiki.centos.org/About/Product
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 22 January 2016 at 16:58, Nick Coghlan wrote:
> I've posted about this idea to the list before, but this time I've
> finally started working on it and have a concrete plan to discuss :)
>
> The basic idea:
>
> * I want to progressively move the active interoperabi
notice that they can
potentially help out with what someone else is working on.
> distutils-sig would really be more accurate
> if it was named packaging-sig, but historical reasons ;)
I kind of look forward to a distant future where we *do* decide to
rename it, as that will mean all of the mor
On 25 January 2016 at 08:32, Nathaniel Smith wrote:
> On Sun, Jan 24, 2016 at 4:08 AM, Nick Coghlan wrote:
>> If the aim is to bring Linux wheel support in line with Windows and
>> Mac OS X, then rather than defining a *new* compatibility tag (which
>> would require new p
at obscure
the main aspects of the dist-info directory and the RECORD metadata
file)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
e CentOS 6+ path, it should make it possible to
take binaries built on the reference environment and use abicompat to
check them against libraries from another distro, and vice-versa.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
On 26 January 2016 at 21:44, Antoine Pitrou wrote:
> On Tue, 26 Jan 2016 20:36:26 +1000
> Nick Coghlan wrote:
>>
>> If I understand the problem correctly, the CentOS 5 gcc toolchain is
>> old enough that it simply doesn't emit the info libabigail needs in
>>
(or we're not on a Linux system).
If "import manylinux" works, then the module can give details (perhaps
pulled from a config file, perhaps figured out on the fly by querying
the running system, perhaps hardcoded by the OS vendor) on the
compatibility level.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
pdate the version in the
> PEPs repo to
> this version?
Done: https://www.python.org/dev/peps/pep-0513/
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.or
On 25 January 2016 at 14:54, Nick Coghlan wrote:
> On 25 January 2016 at 13:30, Donald Stufft wrote:
>> Will we start moving the actual specifications into packaging.python.org, or
>> will they stay in the PEP repository? I’m not sure I can tell from your two
>> PRs curre
on until such
time as we get around to updating the relevant spec.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 26 January 2016 at 23:17, Nick Coghlan wrote:
> On 26 January 2016 at 21:44, Antoine Pitrou wrote:
>> On Tue, 26 Jan 2016 20:36:26 +1000
>> Nick Coghlan wrote:
>>>
>>> If I understand the problem correctly, the CentOS 5 gcc toolchain is
>>> old e
On 27 January 2016 at 22:54, Nick Coghlan wrote:
> I followed this up with the ABI folks, and the problem is that the
> elfutils in even DTS 2 is too old to support building libabigail, and
> later versions of the developer toolset (3 & 4) don't support being
> run on CentOS
or platform modules, while patching them can. That's
still not a guarantee that any given distro will actually provide an
importable "_manylinux" module to indicate compatibility, but given
the fallback glibc check, _manylinux is more a hedge against future
*in*compatibility than it is anything else.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ckages) live
> in PyPI together, there'd be a way to indicate a preference.
I don't think we want to go into that level of detail in the platform
tag, but metadata for bundled pre-built binaries in wheels and
vendored dependencies in sdists is worth considering as an enhancement
in its
On 30 January 2016 at 05:35, Nate Coraor wrote:
> On Fri, Jan 22, 2016 at 6:29 AM, Nick Coghlan wrote:
>> For the time being, these users should either pass the "--no-binary"
>> option to pip, ask their distro to provide an index of pre-built wheel
>> files fo
ys.maxunicode > 0x".
The main reason we need to spell this out explicitly is that while
distros (and I believe other redistributors) build CPython-for-Linux
in wide mode as a matter of course, a Linux checkout of CPython 2.7
will build in narrow mode by default.
Cheers,
Nick.
--
Nic
On 30 January 2016 at 18:37, Nathaniel Smith wrote:
> On Fri, Jan 29, 2016 at 11:52 PM, Nick Coghlan wrote:
>> On 30 January 2016 at 09:29, Nathaniel Smith wrote:
>>> Hi all,
>>>
>>> I think this is ready for pronouncement now -- thanks to everyone for
>
On 30 January 2016 at 23:45, Oscar Benjamin wrote:
> On 30 January 2016 at 08:58, Nick Coghlan wrote:
>>
>> I applied both this iteration and the previous one to the PEPs repo in
>> order to review it, so modulo caching issues, this latest draft is
>> live now.
>
On 31 January 2016 at 02:49, Donald Stufft wrote:
>
>> On Jan 30, 2016, at 3:58 AM, Nick Coghlan wrote:
>>
>> I also think this version covers everything we need it to cover, so
>> I'm going to mark it as Active and point to this post as the
>> resolution :)
On 2 Feb 2016 10:45, "Matthias Klose" wrote:
>
> On 30.01.2016 00:29, Nathaniel Smith wrote:
>>
>> Hi all,
>>
>> I think this is ready for pronouncement now -- thanks to everyone for
>> all their feedback over the last few weeks!
>
>
> I don't think so. I am biased because I'm the maintainer for
oogle-fu)
Cheers,
Nick.
P.S. I'm assuming the existing ability to publish NumPy & SciPy wheels
for Mac OS X is based on Apple's tighter control of their hardware
platform.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 4 February 2016 at 21:22, Nick Coghlan wrote:
> While the manylinux PEP brings Linux up to comparable standing with
> Windows and Mac OS X in terms of distributing wheel files through
> PyPI, that does mean it still suffers from the same problem Windows
> does in relation to Num
row Unicode runtimes in the build
environment, as:
1. Python 2.7 narrow Unicode builds really don't handle code points >=
65,535 correctly
2. Python 3.3+ doesn't have the narrow/wide distinction
3. Canopy users will presumably be getting most of their binaries from
Enthought, not PyPI
ary is available, otherwise skip it" could be a nice way
for software publishers to be able to tweak the install experience of
their package though - everyone gets a clean install experience, but
the folks with relevant pre-built dependencies available get improved
runtime performance.
On 6 February 2016 at 20:35, Marius Gedminas wrote:
> On Sat, Feb 06, 2016 at 03:04:48PM +1000, Nick Coghlan wrote:
>> That means the only folks that seem likely to miss out on pre-built
>> binaries this way would be Python 2.7 pyenv users.
>
> And people who run
gree on (I've
never actually built NumPy et al from source myself, I've always used
the distro packages or conda).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ontiguous storage for
io.StringIO: individual strings use a bit width based on the largest
code point they contain, while io.StringIO's non-contiguous storage
means that if you avoid calling getvalue(), only the segments that
actually contain higher code points need to use the higher
On 6 February 2016 at 21:26, Marius Gedminas wrote:
> On Sat, Feb 06, 2016 at 09:18:39PM +1000, Nick Coghlan wrote:
>> On 6 February 2016 at 20:35, Marius Gedminas wrote:
>> > FWIW the rationale Pyenv gave when they rejected a bug asking for UCS-4
>> > builds by defau
heels built against a
statically linked CPython into a system httpd environment running the
system mod_wsgi. If I've understood the problem description correctly,
that *should* work, but if it doesn't, then it would represent a
significant compatibility concern.
Cheers,
Nick.
--
Nic
as bugs found by working
on the reference implementation (in this case, the Docker build
environment). Finding spec defects after approval is actually a pretty
normal occurrence for PEPs targeting the CPython reference
implementation, as some flaws only become apparent once you put
something to th
only
makes sense in the context of setuptools originally being designed to
serve the needs of the Chandler project).
Cheers,
Nick.
[1] If we never end up with a build system called "rennet", I am going
to be most disappointed :)
pec for sdist 1.0, since that's never previously been officially
defined.
The key difference from setuptools is that the setup.py shim will be a
standard one that flit (and other source archive creation tools) can
inject when building the sdist, rather than needing to be a custom
file sto
effective collaboration between the two
communities, rather than a real solution.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 11 February 2016 at 13:48, Nick Coghlan wrote:
> On 11 February 2016 at 08:12, Barry Warsaw wrote:
>> It's not impossible to migrate to something else, but it's impractical to
>> migrate to dozens of something elses. Right now, if we can count on PyPI
>>
On 11 February 2016 at 17:50, Ralf Gommers wrote:
> On Wed, Feb 10, 2016 at 2:43 PM, Paul Moore wrote:
>>
>> On 10 February 2016 at 13:23, Nick Coghlan wrote:
>> > On 10 February 2016 at 20:53, Paul Moore wrote:
>> >> We don't have to solve the
On 12 February 2016 at 01:19, Barry Warsaw wrote:
> On Feb 11, 2016, at 01:58 PM, Nick Coghlan wrote:
>>Anyway, the core point is wanting to ensure we can automate not only
>>"direct to binary" installation with Python specific tools, but also
>>the "convert to
but those
dependencies should only be needed on 7.0 and 7.1
Unfortunately, I missed this use case when PEP 508 was being defined, so
there's currently no capability for Python level dependencies to be
conditional on the presence or absence of particular attributes in other
modules :(
Regards
s a good, concrete example.
>
I believe tools like pyp2rpm, conda skeleton, py2dsc and fpm also rely on
that static sdist metadata (I'm not 100% sure on that, but it would make
sense for them to do so).
We just spend so much time worrying about the dependency management
problems that
On 19 February 2016 at 16:59, Chris Withers wrote:
> Hi Nick,
>
> On 18/02/2016 13:32, Nick Coghlan wrote:
>
> On 17 February 2016 at 04:37, Chris Withers
> wrote:
>
>>
>> So, RHEL7, for worse or worse, ships with Python 2.7.5.
>
>
> It's 2.7.5
irectly
implementing the underlying interoperability specification.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
se.
Given that, I'm going to go back to reserving judgement on *all* of
the points Robert mentioned, at least until you've had a chance to
finish writing up your own proposal - the determining factor I thought
I had found turned out not to be so determining after all :)
Regards,
Nick.
--
agement process, though:
https://github.com/pypa/pypa.io/issues/11#issuecomment-195412332
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
for maintainers to provide that metadata and keep it up to
date. As a fallback for projects without that metadata, searching
popular hosting sites like GitHub, BitBucket, GitLab and even
SourceForge, would provide some initial links to investigate.
Cheers,
Nick.
--
Nick Coghlan | ncog
oot of the source tree. (The PEP sort of implies this already,
but I didn't see it explicitly stated anywhere)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python
On 21 March 2016 at 23:16, David Cournapeau wrote:
> On Fri, Mar 11, 2016 at 3:26 PM, Nick Coghlan wrote:
>> Proposed errrata & minor admentments for PEP 425 can be submitted as a
>> PyPUG issue with a PR against
>>
>> https://packaging.python.org/en/latest/specifi
open source project to hear a heartfelt "thank you" that it's at
least worth considering taking other replies off list :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
b in 3.3 (the caching avoided a slowdown when
importing from local disks, and provided a dramatic speed *up* when
importing from network file shares).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG m
ps://github.com/pypa/setuptools/blob/master/docs/setuptools.txt#L1273
>
> I guess a PR against the setuptools docs to suggest updated wording
> would be a good start.
Sent: https://github.com/pypa/setuptools/pull/542
Cheers,
Nick.
--
Nick C
0, then 'pip install numpy' should Just Work on linux without
> needing a compiler at all (and likewise on windows and osx).
Woohoo! Congrats to all involved in making that possible :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gm
actical course of action currently available.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
3 cursory checks will find most potential name conflicts before
someone commits themselves to a particular one.
Cheers,
Nick.
[1] http://mython.org/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
rpreter initialisation, setuptools/easy_install, pip, virtualenv,
project setup.py files, and sometimes even the Python Package Index,
and the folks that already have all those moving pieces in their heads
unfortunately tend to have a lot of competing priorities)
Cheers,
Nick.
--
Nick Coghlan |
s making a landgrab for
developer mindshare in the hopes of creating the next Oracle or
Microsoft :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
andoc as a standard dependency), but client-only
changes are generally an easier pitch than changes to the interfaces
between client tools and PyPI.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maill
ld and I are in favor of the python
> hooks approach, and Robert is indifferent between them and just wants
> to move forward, so we agreed that unless anyone objects we'll drop
> the command-line approach and go ahead with refining the Python
> function call approach. So... if
for Debian. If you
search for "pybuild.json" instead, then the 3rd-ranked link, at least
for me, is Antoine Pitrou's original suggestion of that name back in
November.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
an ini-like file
that can mostly replace the setup.py file."
The build system abstraction config could then also just be another
setup.cfg section.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG m
Nick.
P.S. Fun fact: XML (as formally specified) is a customisation
language, rather than a configuration language. If you want to safely
use it as a configuration language, you need to use a library like
defusedxml to cut it down to a non-Turing compl
rdised interface.
Don't get me wrong, I still think that answer has significant
downsides - I've just come around to the view that "is likely to be
easy to implement and adopt" are upsides that can outweigh a whole lot
of downsides :)
Cheers,
Nick.
--
Nick Coghlan |
On 5 May 2016 at 14:22, Nathaniel Smith wrote:
> On Wed, May 4, 2016 at 6:28 AM, Nick Coghlan wrote:
>> On 4 May 2016 at 23:00, Daniel Holth wrote:
>>> +1 It would be great to start with a real setup_requires and probably would
>>> not interfere with later build
pypi_modules_as_rpm_packages/index.html
[2] https://github.com/pypa/interoperability-peps/pull/30
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
of inapplicable documentation of the setuptools feature
:)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 6 May 2016 at 06:30, Chris Barker wrote:
> On Wed, May 4, 2016 at 7:45 PM, Nick Coghlan wrote:
>> Usually that enforcement is
>> handled by making the configuration declarative - it's in some passive
>> format like an ini file or JSON, and if it gets too repetiti
301 - 400 of 1620 matches
Mail list logo
