On 7 Jun 2014 06:08, "Donald Stufft" wrote:
>
>
> On Jun 6, 2014, at 9:41 AM, holger krekel wrote:
> >
> > Once you care for ACLs for indexes and releases you have a number
> > of issues to consider, it's hardly related to PEP470/PEP438.
>
> It is related, because it means that the exact same mec
mething we'll want to keep an eye on, but yeah, at this point
in time, when connecting an IPv6-only system to the internet, PyPI is
likely to be long way down the "it isn't working" priority list.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
ve IPv6 websites and it has my remote backups and
> git-annex repositories.
I was thinking of the client case, but you're right, in a server
context, IPv6 only is far more likely to be viable already.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 13 Jun 2014 02:01, "Donald Stufft" wrote:
>
> Not currently. There’s an open issue about how to handle that within
Wheels as a few projects need those kinds of hooks.
To elaborate a little further on that, install time scripts are one of the
main motivators for "required extensions" in PEP 426
but behind
the migration to Warehouse on the list of things to be worked on (it
also depends on the improved handling of build dependencies that is
part of the metadata 2.0 definition). Donald could provide a better
update than I can in terms of the current status of the Warehouse
migration, an
somewhere?
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 29 Jun 2014 07:29, "Jim Fulton" wrote:
>
> You also don't need tools to automate deployment of production
> configurations when an application is deployed, as this is mostly done
> when building an image. The isolation provided by docker containers
> also allows configuration to be simpler. Th
On 3 July 2014 03:24, Reinout van Rees wrote:
> On 30-06-14 17:56, Nick Coghlan wrote:
>>
>> Yeah, it's the "you still need a way to define what goes into the image"
>> part that intrigues me with respect to combining tools like zc.buildout
>> with Docke
On 14 Jul 2014 17:11, "Erik Bray" wrote:
>
> Still, if anyone else has further thoughts on this topic I'd be
interested.
Twisted still has the most sophisticated approach to NEWS files I've seen:
https://twistedmatrix.com/trac/wiki/ReviewProcess#Newsfiles
The upcoming PEP 459 python.details exte
On 17 Jul 2014 05:28, "Richard Jones" wrote:
>
> Thanks for the feedback, Josh.
>
> The Python 3 version of the distutils documentation is far improved on
this topic, I believe (though please, file a bug / change if you can
improve it :)
>
>https://docs.python.org/3/distutils/sourcedist.html#m
On 17 Jul 2014 15:10, "Paul Moore" wrote:
>
> Longer term, maybe your use case is something that we could support
> via Metadata 2.0.
For the record, the current draft of the python.commands extension in PEP
459 does indeed include support for reporting prebuilt commands:
http://www.python.org/de
On 17 Jul 2014 16:15, "David Genest" wrote:
>
> > For the record, the current draft of the python.commands extension in
PEP 459 does indeed include support for reporting prebuilt
> > commands:
http://www.python.org/dev/peps/pep-0459/#the-python-commands-extension
> > The draft metadata extensions
vent having to hop around between setuptools and
> distutils.
Woohoo! Just knowing you're working on it is helpful - it's one of the
big items on my wishlist that I couldn't even consider writing myself,
since I don't know setuptools *or* distutils anywhere near well enough
:)
On 24 Jul 2014 03:09, "Richard Jones" wrote:
>
> I believe the current PEP addresses the significant usability issues
around this by swapping them for other usability issues. In fact, I believe
it will make matters worse with potential confusion about which index hosts
what, potential masking of r
On 25 Jul 2014 02:05, "Donald Stufft" wrote:
>
> Sorry, I think the provides functionality is outside of the scope of what
we would use TUF for. It is *only* respected if you have that project
installed. In other words if there is a package “FakeDjango” which provides
“Django”, then ``pip install
On 25 Jul 2014 17:46, "Chris Withers" wrote:
>
> On 24/07/2014 17:44, Daniel Holth wrote:
>>
>> Also, reject uploads that are not released under a DFSG license
>
>
> What's a DFSG license>
>
>> or lack
>> man pages.
>
>
> Are you serious?
I took it as a sarcastic comment cryptically expressing di
*link* to the
> externally-hosted file from PyPI, rather than that file's content. It is
> more error-prone, but avoids issues of file ownership.
This is essentially what PEP 470 proposes, except that the link says
"this project is hosted on this external index, check there for th
On 25 July 2014 23:34, Donald Stufft wrote:
> On July 25, 2014 at 9:29:14 AM, Richard Jones (r1chardj0...@gmail.com)
> wrote:
>
> On 25 July 2014 15:21, Nick Coghlan wrote:
>>
>> On 25 July 2014 23:13, Richard Jones wrote:
>> > A variation on the above two idea
On 26 Jul 2014 05:56, "Donald Stufft" wrote:
>
> On July 25, 2014 at 3:50:30 PM, Wichert Akkerman (wich...@wiggy.net)
wrote:
>> Will that guarantee the OS-provided Python was used? Or is there still a
risk someone was using a custom compiled Python on an Ubuntu 14.04 system
that is not binary comp
r case, by SCL enabling other
packages, we make it possible to test those packages against Python
3.5, even though it hasn't been released yet (and ditto with
unreleased pip, setuptools and wheel commits). Users don't have to
mess about manually figuring out h
On 26 July 2014 18:28, Ronald Oussoren wrote:
>
> On 26 Jul 2014, at 08:54, Nick Coghlan wrote:
>> Yes, by "system Python" on Linux, I mean the distro provided one.
>> (Technically Apple provide one as well, but binary compatibility there
>> is still governed
dows and Mac OS X.
It avoids a lot of the gnarly dependency management problems.
Unfortunately, there's no generally accepted technique for automating
it at this point (Although there's an issue open suggesting the
addition of a feature along these lines to devpi:
https://bitbuc
On 29 Jul 2014 03:43, "Giovanni Bajo" wrote:
>
> Hello,
>
> on March 2013, on the now-closed catalog-sig mailing-list, I submitted a
proposal for fixing several security problems in PyPI, pip and
distutils[1]. Some of my proposals were obvious things like downloading
packages through SSL, which wa
On 29 Jul 2014 10:01, "Giovanni Bajo" wrote:
>
> Il giorno 29/lug/2014, alle ore 01:36, Nick Coghlan
ha scritto:
>>
>> On 29 Jul 2014 03:43, "Giovanni Bajo" wrote:
>> >
>> > Hello,
>> >
>> > on March 2013, on the now-
On 29 July 2014 11:50, Ian Cordasco wrote:
> On Mon, Jul 28, 2014 at 8:12 PM, Giovanni Bajo wrote:
>> Il giorno 29/lug/2014, alle ore 02:39, Nick Coghlan ha
>> scritto:
>>> If your PEP defends against all the attacks TUF does, then it will be just
>>> as complic
On 12 Aug 2014 01:23, "Donald Stufft" wrote:
>
>
>> On Aug 11, 2014, at 11:11 AM, Marcus Smith wrote:
>>
>> > Public index servers SHOULD NOT allow the use of local version
identifiers for uploaded distributions.
>>
>> I'm thinking this should just say "PyPI" and not "Public" broadly.
>> The poin
ocal
> version. At the point you’re doing more than simple patching you’re probably
> making a full fledged fork which should have it’s own name and version
> numbers I think?
Agreed. For use of the local version field to be appropriate, we
should be looking at full API compat
ing to an approach more in line with the
Zen of Python :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
n of PEP 386
back in June 2009, more than five years ago!
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 28 Aug 2014 05:56, "Daniel Holth" wrote:
>
> Tell me more about setup-requires. It's nice to hear it has users. Should
we promote it to a pypa project?
That would be cool - bootstrapping as much as we can *without* metadata 2.0
has the virtue of working in many more environments :)
Cheers,
Ni
On 29 Aug 2014 08:27, "Donald Stufft" wrote:
>
>
> Just thought of this, if the normalized name doesn’t match the "real"
name,
> then add entries for both. This will make it so that pip 1.5 continues to
work
> and pip 1.6+.
Having bandersnatch mirrors publish under both names sounds like a good
a
On 2 Sep 2014 03:19, "Marcus Smith" wrote:
>
>
>>
>> My view is that Python packaging should not support installation of
>> files to anywhere other than subdirectories of the scheme [...]
>>
>> For packages that need to install to absolute locations, I would
>>
>> suggest that this be handled by a
Ideally, we'd have an integration environment where tests for pip,
bandersnatch and devpi were all automatically run against pypi commits
before they went live, but that's rather a lot of work to set up.
Until we have such a system, we may continue to see occasional
incidents like this o
n.org/peps/rev/ff38b758e584
Thanks for pointing it out!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
sing.
(FWIW, the only major barrier I see to formalising the metadata 2.0
spec at this point is the lack of up to date jsonschema files. Getting
that out the door may be something to explore post pip 1.6)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austral
x27;d like to add to PEP 459.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ly reverted.
Regards,
Nick.
P.S. OK, I take back my earlier comment about PEP 426 being almost
ready to go :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 13 Sep 2014 00:20, "Paul Moore" wrote:
>
> Yes, it sounds like things are getting complex here and I'm not sure I
> follow why. At the moment, the metadata for a distribution is
> generated when setup.py is run, and is stored in the wheel and in the
> installed dist-info directory when the dis
intertwined, so describing them together made it easier to ensure they
were consistent (and sufficiently comprehensive).
2. It also meant they were *approved* together, in advance of the rest
of PEP 426. An agreed version numbering scheme on its own isn't
particular useful, without a way to
On 17 Sep 2014 03:02, "Vinay Sajip" wrote:
>
> From: Paul Moore
>
>
> > One thing that might be worth clarifying somewhere/somehow (not
> > particularly in the specs, though) is where is the best place to find
> > the "canonical" implementations of the various metadata specs. At one
> > point, di
table
with "this may break without warning", then they can stick to the
stable packaging/pip layer.
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 18 September 2014 10:08, Donald Stufft wrote:
> On Sep 17, 2014, at 1:05 AM, Nick Coghlan wrote:
> Perhaps we should make that official policy? Anything in PEP 426 and
> PEP 459 (and other packaging metadata and installation database
> related PEPs) needs to be trialled in di
What about an approach where pip first tries the canonical name, and if
that fails, tries the exact given name?
Seems to me like that should handle legacy mirrors without the big download.
Cheers,
Nick.
___
Distutils-SIG maillist - Distutils-SIG@pytho
On 18 Sep 2014 17:48, "Nick Coghlan" wrote:
>
> What about an approach where pip first tries the canonical name, and if
that fails, tries the exact given name?
And by canonical I mean normalised.
>
> Seems to me like that should handle legacy mirrors without the big
downlo
t; saying that they have a package that they wrote, but
> that they no longer wish to maintain.
>
> I don't know, I'm just tossing out some potentional ideas!
Yep, for this kind of thing, "automate" can be a better answer than
"document" - it's much easier to d
ocal.readthedocs.org)
We probably don't need to go that far, but it would be one possible
way for project maintainers to explicitly tell the PyPI admins about
lack of availability, without needing to change PyPI itself, and
without trying to manage such notifications manually via email.
steps up
> to take it over, you could create a team and put both people in it, then
> transfer the ownership to that team.
That's sort of what happens now - the requestor is *added* to the
admin list, but the previous maintainer remains as co-owner.
Regards,
Nick.
--
Nick Coghlan
On 23 Sep 2014 00:19, "Antoine Pitrou" wrote:
>
> Donald Stufft stufft.io> writes:
> >
> > PyPI inherinently has complete control over who owns what name on PyPI.
>
> Political authority does not derive from technical control, though.
>
> > As Toshio said that are situations where it makes *obvio
On 26 Sep 2014 01:15, "David Cournapeau" wrote:
>
>
>
> On Wed, Sep 24, 2014 at 7:49 PM, Paul Moore wrote:
>>
>> On 24 September 2014 17:24, Chris Barker wrote:
>> > Thanks -- that would be great. But really, why is this so hard? Win64
is
>> > essentially One platform, and the freely available S
s available from:
> http://aka.ms/vcpython27
Wonderful news Steve, thanks!
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 29 Sep 2014 07:37, "M.-A. Lemburg" wrote:
>
> -1.
>
> It does happen that files need to be reuploaded because of a bug
> in the release process and how people manage their code is really
> *their* business, not that of PyPI.
>
> FWIW, I am getting increasingly annoyed how PyPI and pip try to di
On 29 Sep 2014 18:49, "M.-A. Lemburg" wrote:
>
> You are missing out on cases, where the release process causes files to
> be omitted, human errors where packagers forget to apply changes to
> e.g. documentation files, version files, change logs, etc., where
> packagers want to add information tha
On 29 Sep 2014 19:04, "M.-A. Lemburg" wrote:
>
> Do you seriously want to force package authors to cut a new release
> just because a single uploaded distribution file is broken for
> some reason and then ask all users who have already installed one
> of the non-broken ones to upgrade again, even
On 29 Sep 2014 19:50, "Nick Coghlan" wrote:
>
>
> On 29 Sep 2014 19:04, "M.-A. Lemburg" wrote:
> >
> > Do you seriously want to force package authors to cut a new release
> > just because a single uploaded distribution file is broken for
> >
On 29 Sep 2014 21:04, "Donald Stufft" wrote:
>
>
>> On Sep 29, 2014, at 6:01 AM, Nick Coghlan wrote:
>>
>> One caveat on this: it would potentially be convenient to have a
"release" field in the wheel naming scheme, and adopt a similar approach
for
On 29 Sep 2014 21:20, "holger krekel" wrote:
>
> (Fixed quoting indent + some own comments)
>
> On Mon, Sep 29, 2014 at 11:04 +, Donald Stufft wrote:
> > On Sep 29, 2014, at 6:01 AM, Nick Coghlan > wrote:
> >
> >> It's the silent substitution
On 30 Sep 2014 00:43, "Donald Stufft" wrote:
>
>
> Yea I don’t think PyPI needs anything for this, if someone wants to do it
they can use testpypi.python.org, or they can stand up a devpi instance
which offers a similar thing plus a lot more for a release process.
It occurs to me that a devpi qui
On 29 Sep 2014 22:09, "Wichert Akkerman" wrote:
>
> On 29 Sep 2014, at 13:58, Nick Coghlan wrote:
>>
>> Right, this is my perspective as well. The point that the wheel format
already includes a build ordering field was significant because that file
naming scheme h
On 30 Sep 2014 19:06, "M.-A. Lemburg" wrote:
> You're regularly bringing up this argument.
>
> Let's just be fair here: external hosting of packages has been made so
> user unfriendly in recent pip releases, that this has pretty much
> become a non-option for anyone who wants to create a user frie
user experience for
external index discovery.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
at rather than a generally reusable
> release source artifact.
Why is your setup.py sdist including autogenerated content? It
shouldn't be doing that.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Dist
binary dependency problem that the
scientific folks are currently using conda to address. It's basically
the point where you cross the line from "language specific packaging
system" to "multi-language cross-platform platform".
That said, pip/wheel *may* get some capabilit
On 2 Oct 2014 06:12, "Paul Moore" wrote:
>
> On 1 October 2014 21:06, Daniel Holth wrote:
> > You are confusing generated entry_points script wrappers with the
> > setup(scripts=...) scripts. The scripts=... scripts should never be
> > skipped, even with --skip-scripts, they should work the same
ved
from the client applications. That aspect should arguably include a
step where the decision on whether or not to disable that support is
based on *looking at the numbers again* before turning the feature off
on the server, and perhaps also monitoring for user complaints for a
period after it i
ould narrow the scope to just server side PyPI changes (with
client updates to report the availability of external repositories
being a quality of implementation issue rather than a hard
requirement).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 5 October 2014 03:21, Donald Stufft wrote:
>> On Oct 4, 2014, at 3:46 AM, Nick Coghlan wrote:
>> So while PEP 470 would allow clients to *consider* dropping link
>> spidering support (and any new clients would be free to never add it),
>> it likely doesn't make se
ir infrastructure in a
dangerously insecure configuration. That has nothing to do with PEP
470.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.pytho
fix on the redistributor side
- upstream initiatives like PEP 426 may help, but a lot of it is going
to be a matter of Linux distros reassessing what services we're able
to provide to the wider open source community.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ny requested package to be
spelled out more clearly?
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 October 2014 20:57, holger krekel wrote:
> On Wed, Oct 08, 2014 at 20:27 +1000, Nick Coghlan wrote:
> Well, for installing NAME from pypi you need to trust that the people
> who registered and maintain NAME are not doing something bad (and the
> machine is not compromised but
gt; for my private packages residing on the extra index.
That's what a default repository *does*. It's always on, unless you
explicitly turn it off. Hence the name *extra index*. The index URL
option is the one to use if you want to *replace* the index.
Regards,
Nick.
--
Nick Cogh
lete all references to private indexes from the PEP, as
they were merely included as an illustration of one of the reasons the
multi-index/alternative-index support already exists. If you find the
example distracting from the actual point of the PEP, then the example
isn't serving its purpose,
f assessment of external
impact applies to pip and the PyPA in general when decided whether a
change can be handled within the scope of an individual project, or if
it needs to be escalated for broader discussion.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 8 Oct 2014 23:40, "M.-A. Lemburg" wrote:
>
> The intention of PEP 435 was to enable pip to evolve independent
> of the Python release process, which is a good thing.
>
> However, your comment that "We are an external project and we are not
> bound by the PEP process." doesn't really pan out in
lger's suggestion correctly, it was just to move the
current "Download URL" links over, rather than the scraped links.
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 12 October 2014 09:49, Donald Stufft wrote:
>
> On Oct 11, 2014, at 7:48 PM, Nick Coghlan wrote:
>
>> On 12 October 2014 04:29, Donald Stufft wrote:
>>>> I plan to put the external repositories (and the commands needed to use
>>>> them)
>>>&
stalling the default dependencies, but it *also*
disables installing the distribution itself.
It would be possible to extend that to "pip install
myproj[-,:self:,core]", where ":self:" would be a new implicit extra
for installing the project itself (to go along with the currentl
On 12 October 2014 21:54, Nick Coghlan wrote:
> On 12 October 2014 21:38, Paul Moore wrote:
>> Is it possible to switch this round somehow, so that I have an "extra"
>> that *removes* some of the dependencies?
>>
>> (I could have 2 projects, a core one and
On 12 Oct 2014 22:36, "Paul Moore" wrote:
>
> On 12 October 2014 13:04, Nick Coghlan wrote:
> >>> Any thoughts on how I could do this?
> >>
> >> I don't know of any current way to do it, and even the more flexible
> >> extras notation i
On 15 Oct 2014 11:16, "Donald Stufft" wrote:
> On Oct 14, 2014, at 8:50 PM, Stefan Krah wrote:
>
> >
> > Anyway, it will be kind of tough to force U.S. exceptionalism via the
terms
> > and conditions on an international body of authors if only uploaded
packages
> > are allowed.
> >
>
> I’m not ev
't complain when a developer
chooses to make use of the external hosting support). The previous
design in PEP 438 ended up failing on both of those counts, which is
why there is now this new proposal to replace it with a different
mechanism that has been designed to address the existing usability
c
d be directly to the board
- dealing with *other people's* trademarks is not something that is
currently delegated to anyone.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
installable via pip install on 2.7 or 3.x
I'd be very wary of including technical requirements like this in the
package transfer process.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG mai
hosted
packages is key to simultaneously respecting the interests of both end
users downloading and discovering packages via PyPI, and developers
retaining autonomy in relation to how they choose to engage with the
intricacies of the global copyright system.
Regards,
Nick.
--
Nick Coghlan | ncogh..
elf really isn't that big a deal as a runtime
dependency - the thing you don't want on your production servers is
the compilers that setuptools needs in order to do anything useful
with extension module source files).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
On 29 Oct 2014 01:02, "David Cournapeau" wrote:
>
> Practically speaking, there is no such a thing as ABI on Linux: even if
you somehow managed to deal with glibc, you would then need to deal with
fortran ABI, then with C++ ABI, etc... Dealing with this at the python
level is simply intractable. T
On 30 Oct 2014 07:20, "Marcus Smith" wrote:
>
> yes, I'm partial to a solution like this prior to wheel 2.0 (that I
imagine would support additional/custom tags)
+1 for being able to add additional custom platform tags in the file naming
convention from me as well. As Marcus noted earlier, even i
way future standardisation can be based on experience rather than
trying to guess potential use cases in advance.
Cheers,
Nick.
>
> On 30 October 2014 11:17, Donald Stufft wrote:
>>
>>
>> On Oct 29, 2014, at 7:57 PM, Nick Coghlan wrote:
>>
>>
>> On 30
On 5 Nov 2014 02:22, "Hari" wrote:
>
> I wrote the code for an Android app. I now need to make it as an
executable app. Which utility to use? Can I use the distutils in the
QPython for this purpose?
If you mean a Python Qt application, then you may want pyqtdeploy (
http://pyqt.sourceforge.net/D
On 9 Nov 2014 22:16, "Vinay Sajip" wrote:
>
> > Thanks, that's very useful feedback. I agree, the need for RDP is very
>
> > Windows-specific - I don't know how common RDP tools are for Unix, but
>
>
>
>
> Not uncommon, AFAIK. For example, I use rdesktop on Lubuntu to access
Windows machines via R
On 9 Nov 2014 22:28, "Nick Coghlan" wrote:
>
>
> On 9 Nov 2014 22:16, "Vinay Sajip" wrote:
> >
> > > Thanks, that's very useful feedback. I agree, the need for RDP is very
> >
> > > Windows-specific - I don't know how commo
rol, but some
aspects should be useful regardless of the specific version control
system.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
;m OK with that - those can just continue to
show up as "linux_x86_64", and PyPI can continue to disallow those
uploads.
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 28 November 2014 at 18:19, Antoine Pitrou wrote:
> On Fri, 28 Nov 2014 16:03:59 +1000
> Nick Coghlan wrote:
>> Here's my proposed change:
>>
>> =
>> The default platform tag is distutils.util.get_platform() with all
>> hyphens - and
On 29 November 2014 at 01:31, Matthias Klose wrote:
> On 11/28/2014 07:03 AM, Nick Coghlan wrote:
>>
>> We've discussed the idea of changing the wheel file naming scheme to
>> deal with Linux previously, but never put together a concrete
>> proposal.
>>
&
On 29 November 2014 at 01:51, Antoine Pitrou wrote:
> On Sat, 29 Nov 2014 01:27:44 +1000
> Nick Coghlan wrote:
>> >
>> > Is this not going to be a slippery slope?
>>
>> Only if folks publish Linux binaries themselves, and that's still a
>> bad idea
On 30 November 2014 at 02:10, Antoine Pitrou wrote:
> On Sun, 30 Nov 2014 01:47:16 +1000
> Nick Coghlan wrote:
>> On 29 November 2014 at 01:51, Antoine Pitrou wrote:
>> > On Sat, 29 Nov 2014 01:27:44 +1000
>> > Nick Coghlan wrote:
>> >> >
>
nnected set of significant
usability issues (which become much harder to ignore once you're
working on secure package distribution infrastructure).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Di
t sure it's a good idea to use pip's internal API (as it's internal,
> and I don't believe it's been designed for use as a library by external
> code).
Agreed - the components intended for external use are the ones being
factored out into the packa
e mechanisms correctly, it could
potentially also be used to address the "no SOABI details" problem on
Python 2.7.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
1 - 100 of 1620 matches
Mail list logo
