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

[Wes Turner]

PEX - Python Executable

- It's a ZIP with an executable header and entry points.

- PEX probably solves for the AWS Lambda case
- PEX is unsupported by PyPI (e.g. sadly doesnt work with DevPi
application-level package repository caching)

http://pex.readthedocs.io/en/stable/

https://github.com/pantsbuild/pex

- PantsBuild builds PEX packages (Twitter)
- Buck Build builds PEX packages (Facebook)

Wheel adds a manifest of checksums (which should be signed, correct?)
-
https://bitbucket.org/pypa/wheel/issues/168/code-to-add-a-wheel-manifest-to-any-zip

Wheel does not solve for everything eggs still solve for. Neither are
perfect:
- https://bitbucket.org/pypa/wheel/issues?status=new&status=open
  - Wheel doesn't support environment markers in requirements.txt
  -
-
https://bitbucket.org/pypa/wheel/issues/168/code-to-add-a-wheel-manifest-to-any-zip


What is the need to reduce/simplify the supported package types? Each have
their strengths.

"Suddenly they wouldn't accept archives which execute arbitrary code
anymore "

I say support them all and don't waste time with complex deprecation and
migration strategies when the code already works.

What's it hurting to continue legacy support? (E.g., specifically,  instead
of throwing a distribution stat up and claiming need to eliminate
everything legacy or exotic,
what are the costs for each option here?

Approaches:
- deprecate legacy and goad migration
- continue supporting a diverse array of python packaging needs

Costs:
- end user developer time
- pypa developer time
- pypa server time

On Wednesday, August 17, 2016, Nick Coghlan <ncoghlan at gmail.com
<javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>> wrote:

> On 17 August 2016 at 23:23, Steve Dower <steve.dower at python.org> wrote:
> > Do you mean like zipapp and *.pyz files?
>
> Pretty much, yeah, but with a more fleshed out workflow that accounts
> for dependency bundling as well - you'd have a relatively normal
> Python app with a setup.py and/or requirements.txt, but be able to
> readily package the whole thing up for distribution.
>
> This kind of thing is *possible* today if you already know what you're
> doing, and at least the AWS Lambda docs are pretty decent when it
> comes to describing how to make it work in their (non-zipapp) usage
> model: http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-
> how-to-create-deployment-package.html
> (I haven't checked the Azure Compute Function docs, and Google Compute
> Function is currently JavaScript only)
>
> However, these kinds of approaches are nowhere near as well fleshed
> out from an automation perspective as traditional Linux web service
> deployment - note that there's no mention in the AWS Lambda docs of
> using a requirements file rather than individual dependency
> installations.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160817/b549cfa7/attachment.html>