Re: [Distutils] new PyPI: a rant from a package maintainer

[Alex Walters]

> Also -- I know that the various tools involved are maintained by different 
> people, but it sure would be nice if, for instance, the latest versions of 
> setuptools and twine would not try to upload non longer supported file types!

The tools should have better reporting on the errors pypi gives, but hard 
coding into the tools what pypi will and won’t accept makes policy decisions on 
pypi more painful to change.

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

Re: [Distutils] new PyPI: a rant from a package maintainer

[Chris Barker]

On Fri, Aug 4, 2017 at 5:42 PM, Lucas Boppre Niehues 
wrote:

>
> The long description was originally Markdown, and converted to RST by
> pandoc. I would 100% understand if this conversion triggered some bug.
>

It's a good idea to run docutils on it yourself -- but in any case, broken
RST has always resulted in plain text rendering on PyPi in the past -- as
it should.

-CHB



-- 

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
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] new PyPI: a rant from a package maintainer

[Chris Barker]

one point:


I probably should have named it something other than /legacy/,
>

yes, it should have -- names matter! and having a "legacy" in teh name when
there is not "modern" or "current", or, indeed, anything else is very
confusing.


 pypi.org, might as well get it all done at once. It might be reasonable to
> name it something else now, and just keep the /legacy/ around as an alias.
> I’m not sure if that adds or subtracts from the confusion, but if you think
> that would have helped you, please open a new issue on Warehouse.
>

I think that would be better -- something like "version1" something would
be more clear.

However, we have a major jumble of semi-out of date documentation scattered
all over teh internet -- so ANOTHER name change, might just make things
worse -- it's also confusing to have two names for the exact same thing!

tough call.


> HTTPError: 400 Client Error: Invalid file extension. for url:
https://upload.pypi.org/legacy/

The ability to upload anything besides sdists, wheels, and eggs was
deprecated and removed.

A nice message to that effect would be great.

Also -- I know that the various tools involved are maintained by different
people, but it sure would be nice if, for instance, the latest versions of
setuptools and twine would not try to upload non longer supported file
types!

I've thought for a couple years that we need a setuptool-lite that would
ONLY do what we think is really should do -- but no one ele seemed to think
that would be useful.

> Maybe the tutorial is outdated, and TestPyPI supports auto-registration
now?

I don’t think anyone has kept the tutorial on wiki.python.org up to date.
To be frank, I don’t even know how to update wiki.python.org.

Someone that does really needs to add a "this isn't updated, please see
packaging.python.org note on there !!

As far as keeping PyPI running as well as getting the new code base
> developed and deployed… that’s about it [2]. This is a service used by
> ~everyone in the Python community without even a single full time person on
> it.


This is a core service -- we really need to figure out a better way to keep
it maintained. I suspect the issue is project management, rather than
volunteers -- there are a heck of a lot of talented folks that depend on
these services.

Of course, I have no good ideas about how to move forward -- is there
anyone at the PSF that could take leadership on this?

-CHB
-- 

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
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] status check on PEP 517

[Thomas Kluyver]

On Wed, Aug 2, 2017, at 01:05 PM, Nick Coghlan wrote:
> I wouldn't say that, as the two most clearly side effect free ways of
> putting the source directory on sys.path are:
> 
> 1. make it the current working directory for a "python -m" or "python
> -c" invocation, so that the current directory gets injected as
> sys.path[0] by the interpreter. After all, it's already a requirement
> in the PEP that the current working directory be the directory
> containing pyproject.toml, so this approach handles that as well.
> 2. run a backend script directly (so it's the script directory that
> gets implicitly added to sys.path by the interpreter), and then inject
> the current working directory as sys.path[0] before importing the
> nominated backend
> 
> If a frontend decides to go messing about with PYTHONPATH instead of
> doing either of those, then that's on them (and after it breaks
> horribly, they'll hopefully realise the error of their ways and switch
> to one of the other more reliable approaches).

Nathaniel, can you live with the source directory being on sys.path to
load the hooks? Or would you like to have another go at convincing
people that it shouldn't be?

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

Re: [Distutils] new PyPI: a rant from a package maintainer

[Paul Moore]

On 5 August 2017 at 03:12, Donald Stufft  wrote:
> I’ll see what I can do here. It might just make sense for these related set
> of tools to just ditch the Github issue trackers and share an issue tracker
> that can divide things up by project somehow, but where we can readily move
> issues between them. Maybe we just need something (or someones) able to
> triage incoming issues on a meta tracker and redirect people. Not sure, I’ll
> give it some thought.

I'd be willing to subscribe to a generalised tracker and triage issues
there to direct people to the correct projects. I'm less sure that a
single "Python packaging tools" tracker would be worthwhile (migration
of existing issues seems like it would be a big exercise).

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