Re: [Distutils] Basic Markdown Readme Support

you want to make your README a write-once document, use the format already supported on both platforms. On 5/3/2016 00:27, Robert Collins wrote: On 3 May 2016 4:19 PM, "Alexander Walters" <tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>> wrote: > > I am -1

Re: [Distutils] Basic Markdown Readme Support

I am -1 on this on the basis that the services mentioned also happily support restructured text READMEs On 5/2/2016 12:40, Nick Timkovich wrote: Markdown READMEs are becoming increasingly ubiquitous for many projects. GitHub, GitLab, Bitbucket, among others, happily detect .md readme files

Re: [Distutils] Two ways to download python packages - I prefer one

Hypothetically, the alternative is to break non-application entrypoints (the ones NOT used for console scripts or gui applications) into some other infrastructure. The people that use entrypoints for their plugin systems might be given a build system agnostic option if that were the case.

Re: [Distutils] Parked Names in PyPI under user rodmena

On 4/21/2016 15:02, Chris Barker wrote: Good evidence that the "first come first served, and then you get to keep it forever" is not ideal. Criminal violations of trademark are evidence that its not ideal, and therefor we should make pypi untrustworthy for all other cases? This case is

Re: [Distutils] The mypy package

I described at a high level what mypy-lang does to my wife, and the brief history of this issue. Her blerted out solution was to "just change mypy-lang to annopy" (for annotated python). I am required by marital obligation to bring that forward. On 4/18/2016 18:21, Glyph wrote: On Apr

Re: [Distutils] Name arbitration on PyPI

Here here. As to the concept of a name being community owned vs. registrant owned - I am very opposed to changing the rules mid-stream. If community ownership is to be a thing (and I do not want it to be a thing at all, but if it is), it should be *from this point forward* the names are

[Distutils] Name arbitration on PyPI (was: The mypy package)

The idea of expiring out names has been brought up recently to resolve an issue of two packages, one popular and large; another someone's weekend project. The general idea being that a project maintainer should be forced to renew their contact information, or face the possibility of the PyPI

Re: [Distutils] The mypy package

Greatly expanding the pool of names solves the problem. On 4/18/2016 12:34, Chris Barker wrote: On Mon, Apr 18, 2016 at 8:48 AM, David Wilson > wrote: Namespaces seem like a great idea, then these problems disappear

Re: [Distutils] The mypy package

On 4/18/2016 11:18, Chris Barker - NOAA Federal wrote: Domain names are a different system -- you need to maintain your registration. Except, that wasn't my point. My point was I ignore people asking to buy my domain from me because the registered name is part of my identity. PyPi names, on

Re: [Distutils] The mypy package

On 4/16/2016 14:52, Paul Moore wrote: We >cant unilaterally hand over names on pypi to unrelated.. or even related.. >projects because they have a name someone else wants. What I*meant* to say here was that when a request for a name transfer gets no reply, it's helpful to know if the email

[Distutils] Namespaces (was: The mypy package)

On 4/16/2016 12:53, Donald Stufft wrote: On Apr 16, 2016, at 12:42 PM, Alexander Walters <tritium-l...@sdamon.com> wrote: Another solution like adding namespaces to pypi sounds better to me... but then I think about the nightmare of implementing that in a backwards compatible wa

Re: [Distutils] The mypy package

To what end? As much as old packages cluttering the namespace of pypi is annoying, the only thing that will accomplish is orphaning projects. We cant unilaterally hand over names on pypi to unrelated.. or even related.. projects because they have a name someone else wants. Another solution

Re: [Distutils] How to deprecate a python package

Please keep in mind, my suggestion can be done *today* with zero changes to tooling. On 4/5/2016 18:50, Alex Grönholm wrote: Implementing this on Warehouse and pip would have the added benefit of warning users who have a specific version pinned. As for pip letting stderr messages through,

Re: [Distutils] How to deprecate a python package

if it's emitted on installation? 06.04.2016, 01:37, Alexander Walters kirjoitti: On 4/5/2016 18:34, Glyph wrote: Perhaps, before anyone tries to make pip doing something mechanical about deprecations, we should just have the website itself do this sort of redirect? Removing the download

Re: [Distutils] How to deprecate a python package

On 4/5/2016 18:34, Glyph wrote: Perhaps, before anyone tries to make pip doing something mechanical about deprecations, we should just have the website itself do this sort of redirect? Removing the download would be drastic; giving people an interstitial that says "This package is no longer

Re: [Distutils] How to deprecate a python package

The ideal solution is for the maintainer to release one last version of the package with copious use of the warnings module. We really don't want to redirect people blindly - They may be depending on undocumented-but-still-api portions of the original's code that a replacement package might

Re: [Distutils] [Python-ideas] Version control system link in package meta data

to make the tool suggested really happen. ... Which I guess means Tymoteusz Jankowski should probably get an alpha of such a tool out, and that might provoke the movement needed for the tool to succeed. On 3/12/2016 09:46, Nick Coghlan wrote: On 12 March 2016 at 20:44, Alexander Walters

Re: [Distutils] [Python-ideas] Version control system link in package meta data

(cross-replying to distutils-sig@python.org) For a tool like this to work reliably, the semantics of the project urls would have to change (as of right now, there is no set requirement that a VCS link in project URL's point to clone>), nor is there a requirement that the field even be present.

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 2/1/2016 18:37, 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 Python in

Re: [Distutils] draft PEP: manylinux1

Isnt the entire point of using centos 5 to use an ancient toolchain? On 1/26/2016 06: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

Re: [Distutils] Non English Speaking Users of PyPI - I need Help!

How...does the client side text interact with screen readers? Is that an issue? It sounds like an odd thing to do in the first place... On 1/26/2016 12:16, Donald Stufft wrote: Hello! As many of you are aware there has been an effort to replace the current PyPI with a new, improved PyPI.

Re: [Distutils] heads-up on a plot to bring linux wheels to pypi

On 1/14/2016 06:13, Nathaniel Smith wrote: On Thu, Jan 14, 2016 at 2:19 AM, Nick Coghlan wrote: 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

Re: [Distutils] Installing packages using pip

I perhaps can support added dialogs to IDLE to manage packages (having it shell out to pip, if no api is forthcoming), but I don't think I can support having the repl inside of IDLE intercept pip's command line syntax and do anything OTHER than giving a better error message. On 11/14/2015

Re: [Distutils] Installing packages using pip

import pip pip.install(PACKAGESPEC) something like that? On 11/13/2015 12:42, Chris Barker wrote: On Fri, Nov 6, 2015 at 8:06 AM, Paul Moore > wrote: That's the correct command, but you need to run it from the Windows command prompt,

Re: [Distutils] Installing packages using pip

install foo' and print a more helpful message. On 11/13/2015 15:27, Chris Barker wrote: On Fri, Nov 13, 2015 at 12:09 PM, Nathaniel Smith <n...@pobox.com <mailto:n...@pobox.com>> wrote: On Nov 13, 2015 12:00 PM, "Alexander Walters" <tritium-l...@sda

Re: [Distutils] Which Build Distribution Formats do exist?

On 11/4/2015 15:13, Thomas Güttler wrote: From http://python-packaging-user-guide.readthedocs.org/en/latest/glossary/ Egg A Built Distribution format introduced by setuptools, which is being replaced by Wheel. Which other Built Distribution formats do exist beside egg and wheel? Regards,

Re: [Distutils] Working toward Linux wheel support

On 8/14/2015 16:16, Chris Barker wrote: On Fri, Aug 14, 2015 at 9:17 AM, Steve Dower steve.do...@python.org mailto:steve.do...@python.org wrote: There was discussion about an incompatible_with metadata item at one point. Could numpy include {incompatible_with: scipyx.y} in such a

Re: [Distutils] pip/warehouse feature idea: help needed

On 4/12/2015 21:08, Nick Coghlan wrote: Hence the idea of making the feature accessible through the command line clients, not just the web service. For the love of... Can we get packaging fixed before we start jamming crap onto the tools? Enough already. No. Just No. Never. Stop.

Re: [Distutils] pip/warehouse feature idea: help needed

Is the package index really the best place to put this? This is a very social-networking feature for the authoritative repository of just about all the third party module, and it feels like either it could corrupt the 'sanctity' of the repository (in the absolute worst case), or simply be