Re: [Distutils] PyPI abuse

[tritium-list]

Playing devil's advocate here, do we put a value judgement on the content of a 
module on pypi, even if that content is limited to a single function that just 
prints?  What does that mean for something like a 'metapackage' (a package on 
pypi that has no content, and exists only to install other modules - like a 
project that has been modularized into other packages on pypi)?  I think this 
should be handled on a case by case basis, where someone else comes along 
wanting to use a name currently being used by one of these obvious placeholders.

That said, this looks sketchy, and I would not be shocked to find these names 
being held hostage on some auction site somewhere.  If that is the case, 
burninate them.

> -Original Message-
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Lele Gaifax
> Sent: Monday, April 10, 2017 7:10 PM
> To: Distutils-Sig@Python.Org
> Subject: [Distutils] PyPI abuse
> 
> Hi all,
> 
> I know it's been debated here whether there should be some kind of
> filtering
> on uploaded packages on PyPI, but today someone, either an automated
> tool or a
> silly guy, started to upload dozens of "Xxx 0.1.0" where "Xxx" is some
> "surname", here is latest variant: https://pypi.python.org/pypi/Lykov/0.1.0
> 
> Is there something that can/should be done to stop it?
> 
> Thank you,
> ciao, lele.
> --
> nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
> real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
> l...@metapensiero.it  | -- Fortunato Depero, 1929.
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Python-Dev] pythonhosted.org upload no longer works

[tritium-list]

> -Original Message-
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Guido van Rossum
> Sent: Monday, October 10, 2016 12:27 PM
> To: Donald Stufft <don...@stufft.io>
> Cc: Distutils <distutils-sig@python.org>; Giampaolo Rodola'
> <g.rod...@gmail.com>; python-dev <python-...@python.org>
> Subject: Re: [Distutils] [Python-Dev] pythonhosted.org upload no longer
> works
> 
> Honestly I like readthedocs a lot, and I actually *don't* like docs
> that look too much like the standard Python docs -- it should be clear
> to readers (subliminally, through page style, not just be parsing the
> URL) that they're reading third party docs.
> 

That’s quite tangential to pythonhosted.org hosting documentation... But that 
is a consequence of the theme used by docs.python.org/2/ using the default 
sphinx theme.  That problem was already solved for python3 docs - they don’t 
use the default theme.  I really don’t see how this is related at all to the 
uploading of docs to pythonhosted.org.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] When can we kill Python 2.6 support?

[tritium-list]

Therein lies my suggestion.  Pick a date, announce, give 3 months, then stop 
testing on 2.6

> -Original Message-
> From: Donald Stufft [mailto:don...@stufft.io]
> Sent: Friday, September 2, 2016 6:18 PM
> To: tritium-l...@sdamon.com
> Cc: distutils sig 
> Subject: Re: [Distutils] When can we kill Python 2.6 support?
> 
> 
> > On Sep 2, 2016, at 5:47 PM, tritium-l...@sdamon.com wrote:
> >
> > Nick might have something better to say about this, but I don’t think
> catching enterprise-y linux distros like RHEL out of the blue is a good way to
> go, so even if we decide right now to drop 2.6 support, it shouldn’t actually
> ship with breaking changes for like... 3 months?  Maybe a little more or 
> little
> less.
> 
> 
> Right, I don’t specifically mean immediately ejecting support, but rather
> deprecate and then drop along whatever the normal timeline is for project
> (and stop worrying about 2.6 for new stuff).
> 
> —
> Donald Stufft
> 
> 


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] When can we kill Python 2.6 support?

[tritium-list]

Nick might have something better to say about this, but I don’t think catching 
enterprise-y linux distros like RHEL out of the blue is a good way to go, so 
even if we decide right now to drop 2.6 support, it shouldn’t actually ship 
with breaking changes for like... 3 months?  Maybe a little more or little less.

> -Original Message-
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Donald Stufft
> Sent: Friday, September 2, 2016 5:06 PM
> To: distutils sig <distutils-sig@python.org>
> Subject: [Distutils] When can we kill Python 2.6 support?
> 
> The packaging tools generally support 2.6+ and 3.(2|3)+ and that's sort of
> been
> where they've been at for a while now. I would like to think about what we
> need
> to be to start considering Python 2.6 as "too old" to support. In pip we
> generally follow a usage based deprecation/removal of supported Pythons
> but we
> don't have any real guidelines for when something is at a low enough usage
> to
> consider it no longer supported and we instead just sort of wait until
> someone
> makes a case that it's "low enough".
> 
> This issue tends to impact more than just pip, because once pip drops
> support
> for something people tend to start dropping it across the entire ecosystem
> and
> use pip's no longer supporting it as justification for doing so.
> 
> I would like to take a look at Python 2.6 and try and figure out if we're at a
> point that we can deprecate and drop it, and if not what is such a point.
> 
> Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for
> downloading from PyPI I see the usage is ~3% of downloads are via Python
> 2.6.
> The only thing lower than Python 2.6 that is still supported is Python 3.3.
> 
> Python 2.6 itself has been EOL since 2013-10-29 which is now just about 3
> years
> ago. It's SSL module is not generally secure and requires the use of 
> additional
> installed modules to get it to be so. I believe the only place to get a
> Python 2.6 that is "supported" is through the Enterprise-y Linux Distributions
> like RHEL/CentOS/etc.
> 
> Do we think that a ~3% usage of Python 2.6 and being end-of-life'd for ~3
> years
> is enough to start deprecating and dropping 2.6? If not what sort of threshold
> do we think is enough? It'd be nice to get the albatross of Python 2.6 support
> off from around our necks but I'm not sure how others feel. Obviously all of
> the existing versions of all of the tooling will still be fully functional so
> Python 2.6 users will simply need to not upgrade their tooling to continue to
> work, *but* it also means that they will be left out of new packaging features
> (and likewise, people can't rely on them if they still wish to support 2.6).
> 
> Thoughts?
> 
> —
> Donald Stufft
> 
> 
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

[tritium-list]

I am gung ho on everything in this pep except the sdist format section.

Yes, tar, tar.bz2, tar.xz, tar.Z, .tgz, and tbz can probably go without much 
contest.  I agree with some of the arguments in the inspiring thread that 
brought this up, though, that if there is one, and only one, sdist format, it 
should indeed be .zip, NOT .tar.gz.  If dropping tar.gz is too big of a pill to 
swallow, then both tar.gz and zip should survive, with an encouragement to use 
zip in the future.

> 
> File Extensions
> ---
> 
> Currently ``sdist`` supports a wide variety of file extensions like 
> `.tar.gz``,
> ``.tar``, ``.tar.bz2``, ``.tar.xz``, ``.zip``, ``.tar.Z``, ``.tgz``, and
> ``.tbz``. However, of those the only extensions which get anything more than
> negligable usage is ``.tar.gz`` with 444,338 sdists currently, ``.zip`` with
> 58,774 sdists currently, and ``.tar.bz2`` with 3,265 sdists currently.
> 
> Having multiple formats accepted requires tooling both within PyPI and
> outside
> of PyPI to handle all of the various extensions that *might* be used (even if
> nobody is currently using them). This doesn't only affect PyPI, but ripples 
> out
> throughout the ecosystem. In addition, the different formats all have
> different
> requirements for what optional C libraries Python was linked against and
> different requirements for what versions of Python they support. In
> addition,
> multiple formats also create a weird situation where there may be two
> ``sdist`` files for a particular project/release with subtly different 
> content.
> 
> It's easy to advocate that anything outside of ``.tar.gz``, ``.zip``, and
> ``.tar.bz2`` should be disallowed. Outside of a tiny handful, nobody has
> actively been uploading these other types of files in the ~15 years of PyPI's
> existence so they've obviously not been particularly useful. In addition, 
> while
> ``.tar.xz`` is theoretically a nicer format than the other ``.tar.*`` formats
> due to the better compression ratio achieved by LZMA, it is only available in
> Python 3.3+ and has an optional dependency on the lzma C library.
> 
> Looking at the three extensions we *do* have in current use, it's also fairly
> easy to conclude that ``.tar.bz2`` can be disallowed as well. It has a fairly
> small number of files ever uploaded with it and it requires an additional
> optional C library to handle the bzip2 compression.
> 
> Finally we get down to ``.tar.gz`` and ``.zip``. Looking at the pure numbers
> for these two, we can see that ``.tar.gz`` is by far the most uploaded format,
> with 444,338 total uploaded compared to ``.zip``'s 58,774 and on POSIX
> operating systems ``.tar.gz`` is also the default produced by all currently
> released versions of Python and setuptools. In addition, these two file types
> both use the same C library (``zlib``) which is also required for
> ``bdist_wheel`` and ``bdist_egg``. The two wrinkles with deciding between
> ``.tar.gz`` and ``.zip`` is that while on POSIX operating systems ``.tar.gz``
> is the default, on Windows ``.zip`` is the default and the ``bdist_wheel``
> format also uses zip.
> 
> This PEP proposes that we drop the use of ``.zip`` extensions for sdists on
> PyPI and standardize around ``.tar.gz``. For both extensions there are going
> to
> be automation designed by end users which are making assumptions about
> what the
> file extension produced by the ``sdist`` command will be. Changing either
> default will break some number of those, so by changing the default of
> ``.zip``
> to ``.tar.gz`` we minimize the amount of breakage by taking the smaller
> number
> of users and making them match the larger number. In addition, it's more
> likely
> to see Windows users upgrade their setuptools and Python releases on a
> faster
> timescale than POSIX users. POSIX users often get their Python and
> setuptools
> from their OS vendor and are discouraged or actively prevented from
> upgrading
> them outside of complete OS upgrades while Windows users *must* install
> Python
> and setuptools on their own, and thus are more able to upgrade those pieces
> without triggering a complete OS upgrade.
> 
> While it is true that switching to ``.zip`` would align ``sdist`` with
> ``bdist_wheel`` in terms of format, this is not a very large benefit because
> both formats are able to be manipulated with the Python standard library
> just
> as easily and both require the same C library (``zlib``). It is also true that
> Windows has support for ``.zip`` files out of the box but requires third party
> software for ``.tar.gz``, however only 0.6% of downloads for sdists on PyPI
> are
> initiated by browsers and we can assume that only a fraction of those 0.6%
> are
> Windows users who want to manually extract the file and do not have a
> means of
> extracting a ``.tar.gz``, particularly since Python itself can be used to
> extract a ``.tar.gz`` via the command line since version 3.4. In addition, the
> use of ``.tar.gz`` will result in 

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

[tritium-list]

As a heavy windows user, I think I can say for the vast majority of windows 
users on python (that aren’t brand spanking new at python...)

BURN BDIST_WININST!
BURN BDIST_MSI!

> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> Sent: Tuesday, August 23, 2016 7:25 AM
> To: Paul Moore 
> Cc: Alexander Walters ; distutils-sig  s...@python.org>
> Subject: Re: [Distutils] Deprecating little used file types/extensions on 
> PyPI?
> 
> On 23 August 2016 at 19:36, Paul Moore  wrote:
> > So I don't think that in the medium term there's going to be much
> > practical change in the state of things on Windows:
> >
> > - Users install Python from the published python.org installers
> > - Users install packages using pip and wheels from PyPI
> > - Plus some exceptions, where people need to use sdists, or
> > independently published wheels, or worse still, wininst/msi installers
> > because that's all available
> >
> > Whether that process is manual, or hidden behind some form of scripted
> > process, won't alter the underlying infrastructure.
> >
> > I don't see any sign of *anyone* working on a curated distribution for
> > Windows along the lines of Linux distros or Homebrew. (Unless you
> > count cross-platform stacks like conda, which IMO are a different
> > scenario than "system" Python installs).
> 
> OK, cool - that gives us all the more reason to retain bdist_wininst
> and bdist_msi hosting support. However, I do think it makes sense for
> us to say up front that we'll reconsider that decision if something
> akin to homebrew gains traction amongst developers running Windows the
> way homebrew has amongst open source users running Mac OS X.
> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

[tritium-list]

> The rationale for why the Windows formats get to stay when the other
> platform specific formats are being dropped is implied by that last
> line: we're expecting users on other platforms to be more comfortable
> with using platform specific tooling to manage platform specific
> formats (e.g. the system package manager on Linux, homebrew on Mac OS
> X).
> 
> Cheers,
> Nick.

I'm a heavy Windows user.  Are you aware of a system package manager that I am 
not?  There's nuget (vs), choco (third party) and the Windows Store ...

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposed new Distutils API for compiler flag detection (Issue26689)

[tritium-list]

Changing packaging by updating the standard library will fail.  It’s been 
attempted.

 

The inherent problem is you need to fix packaging for people already using 
python, which means if you add a feature to the standard library, only the 
people who always run the latest and greatest can ever use the feature.  In a 
world where we are talking about Python 3.6/3.7 and python 2.7 is by far the 
most used version of python (and python usage is split pretty evenly between 
3.4 and 3.5 IIRC), no one will use new packaging features in the standard 
library.

 

Putting something in setuptools means it will actually be used.  I think some 
of the goals of this sig is to be able to completely sunset distutils and 
replace it with much better solutions (plural) that all speak the same protocol.

 

From: Distutils-SIG 
[mailto:distutils-sig-bounces+tritium-list=sdamon@python.org] On Behalf Of 
Sylvain Corlay
Sent: Monday, August 22, 2016 2:16 AM
To: Ralf Gommers <ralf.gomm...@gmail.com>
Cc: distutils-sig <distutils-sig@python.org>
Subject: Re: [Distutils] Proposed new Distutils API for compiler flag detection 
(Issue26689)

 

Hi,

On Sun, Aug 21, 2016 at 10:31 PM, Ralf Gommers <ralf.gomm...@gmail.com 
<mailto:ralf.gomm...@gmail.com> > wrote:


On top of that there are technical reasons (don't want to test combinations of 
python + setuptools that both change per release) and organizational ones 
(distutils maintenance is terrible, many simple bugfix patches don't get merged 
for ages, setuptools at least fixes regressions quite fast).

 

I'm not sure if there's an official policy on adding new things to distutils, 
but if not then this request is a good time to make one. Assuming of course 
that the setuptools devs are willing to merge features like the one from 
Sylvain.

 

 

I find this worrying that the main arguments to not include a patch would be 
that

 

 - this part of the standard library is not very maintained (things don't get 
merged)

 - earlier versions of won't have it

 

The former is a bad sign for a standard library and the latter is inherent to 
any new feature. Whether it is a policy or not to not add new features to 
distutils it is clear that a code base that does not evolve is dead.

 

How about, instead, we continue improving it?

 

Sylvain

 

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Switch to upload.pypi.org instead of upload.pypi.io

[tritium-list]

> -Original Message-
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Nick Coghlan
> Sent: Saturday, July 30, 2016 11:56 PM
> To: Donald Stufft <don...@stufft.io>
> Cc: distutils sig <distutils-sig@python.org>
> Subject: Re: [Distutils] Switch to upload.pypi.org instead of upload.pypi.io
> 
> On 31 July 2016 at 13:17, Donald Stufft <don...@stufft.io> wrote:
> > Hey!
> >
> > The PSF was finally successful in purchasing pypi.org from the person who
> previously owned it. Previously discussions had dropped off and we assumed
> we weren’t going to be able to purchase it, so we moved forward with
> pypi.io instead. However, the person recently came back around and was
> willing to sell it this time for a reasonable price.
> 
> Woohoo, that's great news!
> 
> pypi.io was an acceptable fallback, but pypi.org is definitely the
> preferred option :)
> 
> > We don’t have all of the pypi.io domains switched over to supporting or
> preferring pypi.org yet, but I just enabled upload.pypi.org. If you’re 
> currently
> uploading to Warehouse using upload.pypi.io, nothing will break, but I
> suggest switching your URL to upload.pypi.org instead as it may not continue
> to work forever.
> 
> +1 on the recommendation for folks to switch their configuration
> settings, although given that domains aren't that expensive, it's
> probably worth the PSF keeping control of pypi.io as an alias of
> pypi.org at least for a few years (and perhaps indefinitely).

It's important to keep pypi.io around for a while, since pypi.org isn’t 
propagating yet.

> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Contributing money to package authors/maintainers via PyPI

[tritium-list]

I assert that a PayPal Donate link in a readme is sufficient.  Anything more is 
a pure waste of precious PSF and -sig resources.  If a project is large and 
needs significant funding, there are better avenues to get funding from or 
through the PSF.  Besides, I do not want to ask Donald to deal with PCI 
compliance; no matter who writes the patch, he would be the one that needs to 
make sure its correct.

> -Original Message-
> From: Distutils-SIG [mailto:distutils-sig-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Nick Coghlan
> Sent: Friday, July 29, 2016 6:41 AM
> To: Nicholas Chammas <nicholas.cham...@gmail.com>
> Cc: distutils-sig <distutils-sig@python.org>
> Subject: Re: [Distutils] Contributing money to package authors/maintainers
> via PyPI
> 
> On 29 July 2016 at 02:09, Nicholas Chammas <nicholas.cham...@gmail.com>
> wrote:
> > Would it simplify things for the PSF if they partnered with someone who
> took
> > care of moving the money around?
> 
> If a global payments provider came to the PSF (or the Packaging
> Working Group within the PSF) and said "Here's a proposal for you to
> consider and suggest amendments to before we start sending
> implementation patches to Warehouse", then it would likely simplify
> things somewhat (the PSF would mainly just need to review the proposal
> to ensure it didn't jeopardise the PSF's non-profit status, that the
> platform operator had a clear escalation process for folks sending and
> receiving money, and that the terms of the proposal for individual
> publishers were something the PSF was happy to promote to PyPI's
> users).
> 
> However, in terms of designing such a system from scratch, picking a
> default payment platform is a relatively easy part of the problem -
> the design work around how the program is presented to package
> publishers and users, how folks raise questions regarding problems
> with money sent or received, and how we mitigate the chance of horror
> stories as folks naively fail to comply with their local tax laws all
> remain as complex problems to be addressed. (There may also end up
> being some challenges around age verification, as PyPI doesn't
> currently require you to specify your age when signing up, but also
> doesn't currently provide any services where that's a potential
> problem)
> 
> > The PSF, via PyPI, would bring a large, opt-in user base to their doorstep,
> > and in return the payment provider (e.g. Gratipay, Salt) would cut the PSF
> > some tiny slice of each transaction.
> >
> > I don’t know if this tweak makes the proposal more realistic (again, maybe
> > the margins wouldn’t work for the provider)
> 
> It does make it more realistic, but as you note in your parenthetical
> comment, it's an open question as to whether it would be worth the
> investment in design and implementation effort from the side of the
> platform provider (especially if they assume the PSF itself will
> eventually get around to funding something along these lines).
> 
> Regards,
> Nick.
> 
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] on integrated docs in Warehouse and PyPI

[tritium-list]

Is this something that can be deferred until after the launch of warehouse?  I 
am, personally, more interested in pypi features that are broken (because of 
the current codebase’s unmaintainability) that cannot be offloaded to other 
services than the ones that can be offloaded.

 

From: Distutils-SIG 
[mailto:distutils-sig-bounces+tritium-list=sdamon@python.org] On Behalf Of 
Nick Coghlan
Sent: Sunday, June 5, 2016 12:34 AM
To: Donald Stufft <don...@stufft.io>
Cc: DistUtils mailing list"" <distutils-sig@python.org>
Subject: Re: [Distutils] on integrated docs in Warehouse and PyPI

 


On 4 Jun 2016 6:54 am, "Donald Stufft" <don...@stufft.io 
<mailto:don...@stufft.io> > wrote:
>
>
>> On Jun 4, 2016, at 9:33 AM, Nathaniel Smith <n...@pobox.com 
>> <mailto:n...@pobox.com> > wrote:
>>
>> I think everyone would agree that having some nice doc hosting service 
>> available as an option would be, well, nice. Everyone likes options. But the 
>> current doc hosting is unpopular and feature poor, falls outside of the PyPI 
>> core mission, and is redundant with other more popular services, at a time 
>> when the PyPI developers are struggling to maintain core services.
>
>
>
> To add to what Nathaniel said here, there are a few problems with the current 
> situation:
>
> Documentation hosting largely worked “OK” when it was just writing files out 
> to disk, however we’ve since removed all use of the local disk (so that we 
> can scale past 1 machine) and we’re now storing things in S3. This makes 
> documentation hosting particularly expensive in terms of API calls because we 
> need to do expensive list key operations to discover which files exist 
> (versus package files where we have a database full of files).

Amazon do offer higher level alternatives like https://aws.amazon.com/efs/ for 
use cases like PyPI's docs hosting that assume they have access to a normal 
filesystem.

Given the credential management benefits of integrated docs, it does seem 
worthwhile to me for the PSF to invest in a lowest common denominator static 
file hosting capability, even if we also use the PyPI project admin pages to 
promote ReadTheDocs and the static site hosting offered by version control 
hosting companies.

Regards,
Nick.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] comparison of configuration languages

[tritium-list]

I am +1 to TOML; it's INI (a human editable format) with data-types (I think
it is even valid INI).  I find the format pleasant to work with both in the
available libraries and in the editor.


-Original Message-
From: Distutils-SIG
[mailto:distutils-sig-bounces+tritium-list=sdamon@python.org] On Behalf
Of Alex Grönholm
Sent: Saturday, May 7, 2016 4:29 AM
To: distutils-sig@python.org
Subject: Re: [Distutils] comparison of configuration languages

+1. I don't think the pathological cases of YAML syntax are of any 
concern in this context. Plus it has excellent tooling support, unlike TOML.

07.05.2016, 09:25, Fred Drake kirjoitti:
> On May 6, 2016, at 10:59 PM, Nathaniel Smith <n...@pobox.com> wrote:
>> Here's that one-stop writeup/comparison of all the major configuration
>> languages that I mentioned:
>>
>> https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f
> Thank you for this!  A very nice summary.
>
> On Fri, May 6, 2016 at 11:14 PM, Donald Stufft <don...@stufft.io> wrote:
>> While I personally prefer YAML to any of the options on a purely syntax
based
>> level, when you weigh in all the other considerations for this I think
that it
>> makes sense to go with TOML for it.
> I expect either YAML or TOML would be acceptable, based on this.  I'll
> admit that I'd not heard of TOML before, but it warrants consideration
> (possibly for some of my projects as well).
>
> I've spent a fair bit of time using YAML with Ansible lately, as well
> as some time looking at RAML, and don't find myself worried about the
> syntax.  Every oddness I've run across has been handled with an error
> when the content couldn't be parsed correctly, rather than unexpected
> behavior resulting from misunderstanding how it would be parsed.  It's
> entirely possible I just haven't run across the particular problems
> Donald has run across, though.
>
> (The embedded Jinja2 in Ansible playbooks is another matter; let's not
> make that mistake.)
>
>
>-Fred
>

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] ez_setup.py can not get setuptools

[tritium-list]

If you are using ez_setup in your setup.py, presumably you have guarded against 
the presence of setuptools in the target environment.  If you don’t have 
setuptools, you don’t have pip.

 

From: Distutils-SIG 
[mailto:distutils-sig-bounces+tritium-list=sdamon@python.org] On Behalf Of 
Chris Barker
Sent: Friday, May 6, 2016 12:17 PM
To: Benedek Zoltan <benzol...@yahoo.com>
Cc: distutils-sig@python.org
Subject: Re: [Distutils] ez_setup.py can not get setuptools

 

ez_setup.py is pretty darn old.

 

Any reason you can't:

 

python -m pip install setuptools

 

?

 

-CHB

 

 

On Fri, May 6, 2016 at 12:11 AM, Benedek Zoltan via Distutils-SIG 
<distutils-sig@python.org <mailto:distutils-sig@python.org> > wrote:

Hi,

 

I don't know what happened recently. Usually I install setuptools by a script 
using the ez_setup.py script.

 

Recently I get an error:

 

Downloading 
https://pypi.python.org/packages/source/s/setuptools/setuptools-21.0.0.zip

Traceback (most recent call last):

  File "downloads/ez_setup.py", line 415, in 

sys.exit(main())

  File "downloads/ez_setup.py", line 411, in main

archive = download_setuptools(**_download_args(options))

  File "downloads/ez_setup.py", line 336, in download_setuptools

downloader(url, saveto)

  File "downloads/ez_setup.py", line 287, in download_file_insecure

src = urlopen(url)

  File "/usr/lib/python3.4/urllib/request.py", line 161, in urlopen

return opener.open(url, data, timeout)

  File "/usr/lib/python3.4/urllib/request.py", line 469, in open

response = meth(req, response)

  File "/usr/lib/python3.4/urllib/request.py", line 579, in http_response

'http', request, response, code, msg, hdrs)

  File "/usr/lib/python3.4/urllib/request.py", line 507, in error

return self._call_chain(*args)

  File "/usr/lib/python3.4/urllib/request.py", line 441, in _call_chain

result = func(*args)

  File "/usr/lib/python3.4/urllib/request.py", line 587, in http_error_default

raise HTTPError(req.full_url, code, msg, hdrs, fp)

urllib.error.HTTPError: HTTP Error 404: Not Found

 

For now I can copy the package from an old virtualenv, but I'd appreciate a 
better solution/advise.

 

Thanks

Zoltan


___
Distutils-SIG maillist  -  Distutils-SIG@python.org 
<mailto:Distutils-SIG@python.org> 
https://mail.python.org/mailman/listinfo/distutils-sig





 

-- 


Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov> 

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[tritium-list]

> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> As I understand it, it's more a matter of folks finding the context
> switch between Markdown and non-Sphinx reStructuredText a pain (with
> the main differences being double-backticks for inline code and `link
> text `_ instead of [link text](link target) for
> hyperlinks) and not being aware of (or caring about) the dire lack of
> commercial investment in tooling support for upstream Python software
> distribution (since all the redistributors have their own software
> distribution platforms that they recommend their users use instead).

As someone who writes quite a bit of non-sphinx Restructured Text, and a lot of 
Markdown (because I have to), I have zero sympathy for the argument of context 
switching.  I can come up with an overblown analogy, but I will just reduce it 
to "it's not complicated to keep the two syntaxes straight".

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig