into the software distribution
infrastructure. It's not at the top of the priority list right now, but
Guido's keynote made me realise it should be on the list somewhere.
[2]
http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/
--
Nick Coghlan | ncogh..
On 14 Apr 2015 04:04, "Robert Collins" wrote:
>
> Tl;dr: I woud like to change PEP-440 to remove the stigmata around dev
> versions that come between pre-releases and releases.
>
> The basic scenario here is developers and CD deployers building
> versions from VCS of arbitrary commits. So we need
heers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 16 Apr 2015 03:08, "Paul Moore" wrote:
>
> Just to expand on another point in my mail - I'd like *anyone* to
> provide an example of a genuine use case for something they think
> should be a "required" installer extension. I'm not sure such a thing
> actually exists...
The constraints extensio
On 16 Apr 2015 14:34, "Paul Moore" wrote:
>
> By the way. I just did a check through PEPs 426 and 459. Neither one
> currently defines a "postinstall script" metadata item or extension,
> which is interesting given that this discussion started from the
> question of how postinstall actions would b
On 16 April 2015 at 17:42, Wes Turner wrote:
>
> On Apr 14, 2015 7:15 PM, "Nick Coghlan" wrote:
>>
>> [...]
>>
>> The perception that open source software is provided by magic internet
>> pixies that don't need to eat (or at the very least to be
her than needing to update the PEPs
repo.
Thoughts?
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
on to packaging.python.org to
provide the user facing counterpart to the implementor facing PEPs.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
o you should probably do it if you don't
have a strong preference, but not all users will want it, so certain
tools may choose not to do it for reasons that are too context
specific for us to go into in a general purpose specification".
The MUSTs are the "things you may not personall
see
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/add_a_file.html)
rather than generating Windows installers directly (if I understand
the tooling correctly, introducing wix into that process should offer
the same kind of potential for better platform integration that
integrat
but I
have no idea when I'll find time to work on it myself. If anyone had
the time and inclination to start putting something together (perhaps
starting with the already accepted PEP 440), that would be wonderful.
Cheers,
Nick.
>
> holger
>
> On Fri, Apr 17, 2015 at 16:18 -0400
because the FHS support is either hacked in, or managed
externally, there's no way for installers to remap the installation
targets for the "self-contained directory" use case.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
appears to be a reasonably responsive pyserial community on
Stack Overflow: http://stackoverflow.com/questions/tagged/pyserial
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-
oing to be
> uhm, stuck.
You're close, you just need to rely on the fact that build_requires is
a sequence rather than a single mapping:
"build_requires": [
{
"requires": ["SoftCushions","barheater"],
"extra": "warmup"
},
{
"requires": ["cython", "barheater"],
"extra": "c-accelerators"
}
]
That's also how you mix unconditional dependencies with conditional
ones, as well as apply environmental constraints to dependencies
included in an extra. I don't currently have any examples of mixing
and matching in the PEP, but it's *already* a monster document :(
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
me. I'm not
sure how best to document it, though. Perhaps have this initial
increment as an implementation detail, and then formalise it in the
next version of the wheel spec.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 13 May 2015 at 16:19, Ben Finney wrote:
> Chris Barker writes:
>
>> On Tue, Apr 14, 2015 at 8:41 AM, Nick Coghlan wrote:
>>
>> > The point where I draw the line is supporting *dynamic* linking
>> > between modules -
>>
>> I'm confused
FD or third party static HTML hosting. One possible option to
explore that minimises disruption for existing users might be to stop
offering it to *new* projects, while allowing existing projects to
continue uploading new versions of their documentation.
Cheers,
Nick.
--
Nick Coghlan | nc
n X.* is active, everything else is
obsolete
* CPython-style and date-based versioning, with a given maximum number
of active released X.Y versions (e.g. 2), but only the most recent
(according to PEP 440) released version with a given X.Y.* is active,
everything else is obsolete
Pre-release versions cou
entral entity, it is more or less curated -- or at least standardized. And
> if you are going to put a binary wheel up, you need to make sure it matches
> -- and that is less than trivial for packages that require a third party
> dependency -- but building the lib statically and then linking i
adata model.
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 17 May 2015 06:19, "Chris Barker" wrote:
> indeed -- but it does have a bunch of python-specific featuresit was
built around the need to combine python with other systems.
>
>> That makes it an interesting alternative to pip on the package
>> *consumption* side for data analysts, but it isn
t runtime utilities like pkg_resources can work
correctly.
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 18 May 2015 07:32, "Chris Barker" wrote:
>
> On Sun, May 17, 2015 at 12:05 AM, Nick Coghlan wrote:
>>
>> > % pip install --upgrade pip
>> > % pip install some_conda_package
>>
>> This gets the respective role of the two tool
On 18 May 2015 at 14:32, David Cournapeau wrote:
> On Mon, May 18, 2015 at 9:05 AM, Nick Coghlan wrote:
>> Indirection via pip injects the usage of setuptools even for plain
>> distutils projects, and generates https://www.python.org/dev/peps/pep-0376/
>> complian
On 20 May 2015 at 15:38, David Cournapeau wrote:
>
>
> On Wed, May 20, 2015 at 2:25 PM, Nick Coghlan wrote:
>>
>> On 18 May 2015 at 14:32, David Cournapeau wrote:
>> > On Mon, May 18, 2015 at 9:05 AM, Nick Coghlan
>> > wrote:
>> >> Indirecti
l to work reliably is still going to be
difficult (and definitely more complicated than static linking in
cases where data sharing isn't needed), but it's not intractable the
way the general case is.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
atives that are currently still fairly
tightly coupled to the offerings of one particular commercial
redistributor).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 21 May 2015 at 08:46, Nick Coghlan wrote:
> On 21 May 2015 at 03:37, Chris Barker wrote:
>> As such, it _could_ play the role that pip+wheel (secondarily pypi) play in
>> the python ecosystem.
>
> In practice, it can't, as conda is entirely inappropriate as an
s/pep-0470/#deprecation-and-removal-of-link-spidering
That's not a reason to avoid deprecating the documentation hosting
functionality in favour of ReadTheDocs and static HTML hosting
services, just something to take into account.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gma
debian.repackage" or "conda.repackage" which include whatever
additional info is needed to automate creation of a policy compliant
downstream package in a format that's a purely additive complement to
the upstream metadata, rather than being somewhat du
iles work
(http://nixos.org/releases/nix/nix-0.12/manual/#sec-profiles), but
adapted to be compatible with Python's existing *.pth file mechanism.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillis
On 21 May 2015 at 10:52, Wes Turner wrote:
> On May 20, 2015 7:43 PM, "Nick Coghlan" wrote:
>> One of my hopes for the metadata extension system in PEP 426 is that
>> we'll be able to define extensions like "fedora.repackage",
>> "debian.repa
On 22 May 2015 14:21, "Donald Stufft" wrote:
>
> Hey,
>
> I'm happy to say that I've just cut the releases of pip 7.0 and
virtualenv 13.0
> and I have uploaded them to PyPI. For the full list of changes go visit
the
> respective changelogs, however the biggest change here is that in pip 7.0
when
>
nyone would like to
follow through with an actual pull request.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
PMs [1]
Cheers,
Nick.
[1] https://fedoraproject.org/wiki/EPEL
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ost of the folks who currently need this functionality want to
support older versions of Python, so something pip-installable is
actually more use to them than standard library support
3. the folks that *are* currently working on improving the
out-of-the-box experience are working on other asp
en thinner on the ground than
packaging experts :)
It's good to hear Brett's planning to dive into this for 3.6, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
2. In the more complex cases (like 2.7.10), PEP 440 gives the right
answer, while lexical string comparison fails
3. Anything handling environment markers already needs to be able to
handle PEP 440 semantics anyway
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 2 July 2015 at 01:37, Donald Stufft wrote:
> On July 1, 2015 at 12:33:29 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
>> From a "how to fix it?" perspective, I think it makes sense to say
>> that any marker ending in "_version" is compared using PEP 440 v
On 3 July 2015 at 02:03, Donald Stufft wrote:
> On July 2, 2015 at 10:34:35 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
>> That's what I was thinking. The one slight difference is that I don't
>> believe we'd want any special case handling of pre-releases in
>&g
uot; capability to both pip (for installation) and bdist_wheel
(for publication), but I don't know what became of that.
If we had that system, then I think it would be reasonable to allow
Linux uploads with a "pypi_linux_x86_64" override tag - they'd
On 8 July 2015 at 00:07, Antoine Pitrou wrote:
> On Tue, 7 Jul 2015 23:53:59 +1000
> Nick Coghlan wrote:
>> Unfortunately, the compatibility tagging for Linux wheels is currently
>> so thoroughly inadequate that even in tightly controlled environments
>> having a wh
en for seasoned support
engineers.
It seems to me that one possible way to do that might be to change
PyPI from whitelisting Windows and Mac OS X (as I believe it does now)
to instead blacklisting all the other currently possible results from
distutils.util.get_platform().
Regards,
Nick.
--
Nick C
On 10 July 2015 at 00:50, Antoine Pitrou wrote:
> On Thu, 9 Jul 2015 23:50:30 +1000
> Nick Coghlan wrote:
>>
>> As Donald notes, I think we're now in a good position to start making
>> progress here, but the first step is going to be finding a way to
>> ens
ome of which have complicated build-time dependencies, we have
> always provided them as eggs and monkeypatched platform support back in to
> pkg_resources. Now that the PyPA has settled on wheels as the preferred
> binary packaging format, I am pretty heavily motivated to do the work to
> work out all the issues with this implementation.
Thank you!
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ersions of Linux, I mainly want to build them for the
particular ABIs defined by the different Fedora and EPEL versions.
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 aspects. This
approach is even applicable to some "centrally managed data analysis
workstation" cases.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
14.04" and getting a
segfault, you have a pretty good hint as to the likely cause of your
problem.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
cosystem, but there's no reason it has
to be that way - we can do a better job of defining the source
dependencies, and then hook into release-monitoring.org to
automatically rebuild the downstream binaries (including adding new
external dependencies if needed) whenever new upstream releases a
a derived
distro can explicitly identify itself as binary compatible with its
upstream and be able to use the corresponding wheel files.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
oy the folks
around us.
Personal prioritisation of effort is already difficult, and adding
more people in a collaborative prioritisation process certainly
doesn't make that any easier :)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
While I don't have a strong personal preference one way or the other,
finding a way to reuse that does seem like it could be an interesting
architectural alternative to building signing capabilities directly
into Warehouse itself.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
style usage of namespace packages likely makes
sense, and only claim additional names on PyPI if they want to promote
a package out of their custom namespace and into the global one.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 1 September 2015 at 00:17, Paul Moore wrote:
> On 31 August 2015 at 14:32, Nick Coghlan wrote:
>> It *may* be worth hacking in special case handling for the packages
>> already hosted externally, but we can do that as exactly that (i.e. a
>> special case providing a lega
edocs.org/en/latest/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
the
PEPs negotiate changes.
It's only the interoperability specs where we currently follow the RFC
model of having the same document describe both the end result *and*
the rationale for changes from the previous version, and I mostly find
it to be a pain.
Regards,
Nick.
--
n-pip be installed manually from EPEL, and that's unlikely to
change (we'd prefer folks switch to using a more easily updated
Software Collection runtime instead of running directly in the system
Python).
Cheers,
Nick.
--
Nick Coghlan | nc
On 5 September 2015 at 12:14, Donald Stufft wrote:
> On September 4, 2015 at 10:12:08 PM, Nick Coghlan (ncogh...@gmail.com) wrote:
>> It's only the interoperability specs where we currently follow the RFC
>> model of having the same document describe both the end result *and*
FL-Delegates for distutils-sig PEPs,
so we can try to be consistent about things :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
maintainability
concerns. Guido did something similar when he asked Mark Shannon to be
BDFL-Delegate for PEP 484's gradual typing).
Regards,
Nick.
P.S. It's becoming clear to me that I should probably write a
companion PEP to PEP 1 that specifically describes distutils-sig&
implementor facing specifications
to end user facing parts of the user guide - at the moment, there's no
standard discoverability path from PEPs like PEP 440 to
packaging.python.org at all.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 5 September 2015 at 16:43, Nick Coghlan wrote:
> On 5 September 2015 at 14:24, Marcus Smith wrote:
>>> I don't have a specific problem with the specs living somewhere else
>>> as well, I just don't think moving a lengthy document full of edge cases
>>>
ied there without
requiring a new PEP (modulo people's time to do the work, but at least
having a place for such specs to *go* would be a good first step).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Stufft wrote:
>>
>> If it’s more useful we could also just use an RFC repository like Rust
does instead of doing a mishmash between having Python using PEPs and
packaging using PEPs.
>>
>> On September 4, 2015 at 11:42:21 PM, Nick Coghlan (ncogh...@gmail.com)
wrote:
>
On 6 Sep 2015 10:39, "Marcus Smith" wrote:
>
> yea, I like the idea of our own authoritative Pypa project for proposals,
and maybe have it hold the final "Specs" we're talking about as well (and
just have PyPUG link to them or whatever).
>
> I *think* it would lower the bar for people considering
ead).
> which fedora version did this start?
I think it was F21 (Dec 2014), may have been F22 (May 2015).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ol or something, right?
Yes, but I think that's easy enough to handle by having a default URL
that always goes to the latest version of the spec, and moving
previous versions to URLs that include the version number.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aus
even though we'd be moving the support repos first in any actual
rollout: https://mail.python.org/pipermail/core-workflow/2015-August/000189.html
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maill
On 7 September 2015 at 09:42, Ben Finney wrote:
> Nick Coghlan writes:
>
>> On 7 September 2015 at 02:09, Marcus Smith wrote:
>> > For example, down the road when there's Wheel 2.0, what's the "Current
>> > Specs" for wheel?
>>
>
ct unqualified links to qualified ones if we
wanted to. I just don't want to :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
structure that will help inform
the metadata 2.0 design.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 8 September 2015 at 10:43, Nick Coghlan wrote:
> On 8 September 2015 at 03:05, Wes Turner wrote:
>> On Sep 5, 2015 11:12 AM, "Donald Stufft" wrote:
>>> > This could later be extended to more meta data, such as platform
>>> > tags, distribution
ification, with versionadded tags
for everything introduced post 1.0.
Then, rather than referring to PEP 425 specifically as it does today,
the wheel 1.x specification would instead refer to
https://packaging.python.org/specifications/compatibility-tags-1.x.html
Cheers,
Nick.
--
Nick Coghlan
n-place for backwards compatible changes, and that this is by design
- we're applying iterative design principles to software distribution
interoperability specifications, so this isn't a "set it and forget it
forever" kind of exercise on the part of tooling develope
bility-peps" was set up to also encompass PyPI API PEPs,
but have never managed to block out the time needed to actually do it.
Thanks for getting that process started.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
in the
packaging user guide that talks about "The second release", as
*that's* where the value of things like testing ("How do you know that
everything you published the first time still works?") and semantic
versioning ("How do your users know whether or not your
detected a binary incompatibility:
https://www.python.org/dev/peps/pep-0459/#the-python-constraints-extension
The equivalent in a pre-metadata 2.0 world would be yet-another-file
in the dist-info directory.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
e want to formalise *now* in
a JSON format aimed at the *current* capabilities of the ecosystem, we
may want to push some of the ideas like metadata extensions and the
finer granularity of dependencies out to a more speculative metadata
3.0 spec, and descope 2.0 to a "only incremental addit
ging is to allow
> people to move away from distutils/setuptools, as the underlying design is
> fundamentally difficult to extend.
We still need a migration path to modern metadata standards for
everyone using distutils and setuptools - that's the side of things
that caused major problems for
On 23 October 2015 at 23:12, Nick Coghlan wrote:
> The core problem is that the status quo is merely clumsy and
> inelegant, rather than completely unusable. For all their flaws, both
> hobbyists and professional developers *can* use the current tools to
> distribute software (and t
On 22 October 2015 at 18:07, Thomas Güttler
wrote:
> Am 21.10.2015 um 17:05 schrieb Nick Coghlan:
>> On 21 October 2015 at 14:55, David Cournapeau wrote:
>>>
>>> On Wed, Oct 21, 2015 at 12:52 PM, Thomas Güttler
>>> wrote:
>>>> ok, at the moment s
need to ensure any improvements we make benefit *existing* projects,
even if they never get updated again.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
easier to deal with than
writing directly for the native installer toolsets on each target
platform), while in any organisation that uses Python heavily, setup
scripts for new projects are likely to be either generated from
templates or copied from those for old projects, rather than needing
to be writte
On 28 Oct 2015 09:32, "Marcus Smith" wrote:
>
> my intention certainly wasn't to try to exclude anybody. for me, it's
the practical matter of the PR UI being more effective than a mailing list
thread (in this case referring to a gist), and that we can track proposals
easier and link to them from
On 26 Oct 2015 01:10, "Paul Moore" wrote:
>
> On 24 October 2015 at 20:25, Marcus Smith wrote:
> > As someone who has slowly chipped away on the PyPUG for the last 2
years,
> > I'm excited about the prospect of being able to make a big jump in
quality
> > very quickly.
>
> Agreed - this is great
On 27 Oct 2015 13:30, "Daniel Holth" wrote:
>
> Mr. grumpy pants,
>
> Now you're trolling us by describing flit.
I'd managed to miss Flit's creation, so I simply wasn't aware of it.
Now that I've had a chance to remedy that oversight, yes, flit sounds
exactly like what I meant, so it could be wo
Caught up on distutils-sig this morning - I don't have any additional
comments on Robert's and Nathaniel's draft PEPs except to say "I really
like the look of where they're going, and look forward to reading the next
iterations on them that take into account the feedback already received" :)
The i
On 28 Oct 2015 11:39, "Nathaniel Smith" wrote:
>
> On Oct 28, 2015 3:25 AM, "Nick Coghlan" wrote:
> >
> [...]
>
> > From an sdist metadata perspective, though, I think the right thing to
do is to descope PEP 426 to just the stuff we *need* for the bui
On 28 Oct 2015 10:08, "Nathaniel Smith" wrote:
>Though it may well make sense for
> the PyPA packaging guide to add a set of best-practice guidelines for
> build system implementors.
What would be really nice is if the new specification came with a
behavioural test suite (e.g. defined with a proj
On 28 Oct 2015 20:10, "Donald Stufft" wrote:
>
> No, I’m suggesting that the PyPA needs to be conservative with it’s
recommendations and that we need to consider the broader ecosystem impact.
Individual projects or people may have different criteria they use to
determine what is an acceptable solu
On 29 Oct 2015 00:31, "Ralf Gommers" wrote:
>
>
>
> On Tue, Oct 27, 2015 at 5:45 PM, Brett Cannon wrote:
>>
>>
>> Nathaniel's comment about how this might actually give pip a leg up on
conda also sounds nice to me as I have enough worry about having a fissure
in 1D along the Python 2/3 line, and
On 29 October 2015 at 02:09, Robert Collins wrote:
> On 28 October 2015 at 23:39, Nathaniel Smith wrote:
>> On Oct 28, 2015 3:25 AM, "Nick Coghlan" wrote:
>>>
>> [...]
>>> From an sdist metadata perspective, though, I think the right thing to do
>
ity providers
GitLab supports: http://doc.gitlab.com/ce/integration/omniauth.html
One of the relevant benefits of migrating to a full repository
management server (whether that's GitHub or GitLab) is that we'll be
able to get away from the current manual approach to managing SSH keys
On 31 October 2015 at 14:15, Wayne Werner wrote:
> First, do no harm, eh?
I haven't had time to watch it yet so I don't have the full context of
the observation, but that's only true if current users are considered
categorically more important than future users. That's a dangerous
line of thinkin
of running
"setup.py".
That way, instead of the static setup.py needing to be copied and
pasted into each project, there's just another line in the config file
like:
[bootstrap]
setup_requires = my_build_system
setup_cli_module = my_build_system.setup_cli
If setup_cli_module isn't specified, then pip will expect to find a
setup.py in the project directory.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
faults to being Donald's call as lead
maintainer, for other interoperability specs, it defaults to me.
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 10 November 2015 at 16:14, Nick Coghlan wrote:
> On 30 October 2015 at 16:27, Marcus Smith wrote:
>>>
>>> =
>>> Whenever a new PEP is put forward on distutils-sig, any PyPA core
>>> reviewer that believes they are
is specified, there can be a default provider in pip
that knows how to invoke the setup.py CLI (or perhaps even implements
looking up the CLI to invoke from the source tree metadata).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
ot; launcher - make it
natively multi-version aware, and have it choose a well-defined
default target version if multiple versions are available.
Longer term, it may even make sense to take the "python" command on
*nix systems in that direction, or, at the very least, make "py&qu
ively
> between well defined expressions now.
Right, Vinay pointed out that the use of parentheses for grouping
wasn't well defined in 345, but instead grew implicitly out of their
evaluation as a Python subset. I attempted to fix that in 426, but
didn't intend to allow non-comparis
201 - 300 of 1620 matches
Mail list logo
