Tarek,
Your proposal is a partial alternative to PEP 390, and is a quite interesting work to dig in, and the SIG is discussing it, but a very important point about it is that it does a lot more. It's a new *building* system on its own, and does not limit itself to describing metadata fields.
Actually no, the proposal is only for a metadata installation of packages that addresses the security problem of requiring users to run untrusted and
unverified setup.py's.
That was where this discussion originated and that is what I am addressing.
PEP-390 doesn't go there at all...
My proposal uses the static metadata contained within existing package formats (PKG_INFO + sources.txt) and therefore doesn't require any changes to the build system.
There isn't a new build system. I never proposed that.
However PEP-390 does imply changing the build system.
That's why you can't just drop a counter-PEP to any existing PEP we have started for Distutils. Imho help us build those PEPs, and / or create your own build system, wether its based or not on Distutils.
Once again, I can't see why all the fuss.
All I did was have a discussion on distutils-ml about a different way of specifying package dependencies that might work across different python platforms.
It was suggested to me that I do a PEP..
So I took the documentation on face value that developers could submit a PEP-proposal.
Imho help us build those PEPs,
This could best apply to PEP-345:
(PKG_INFO) Requires: sys Requires(python <= 2.4): lxml Requires(windows): win32com Requires(linux): pyodbc Requires(linux ubuntu gnome python <= 3.4): gix Requires(windows xp python < 2.2): win32prn
Thank's for reading my alternate-metadata installation proposal and I accept your feedback. What I can do is clarify that my proposal is not for a build system but for a metadata installation scheme based on a static setup.py, existing metadata and use of "python -m setup install" for invocation.
I'm just trying to make this stuff no more complicated than it needs to be...
David