Hi,
I'm posting here to raise awareness about a new Draft packaging
interoperability PEP I am proposing [1].
This document originated from the need to implement pip issue #609 [2],
ie improving the behavior of pip freeze in presence of distributions installed
from direct URL references.
In a thread [3] on discuss.python.org it was suggested a new PEP was needed
to standardize the recording of the required information in .dist-info.
After investigation, I found out PEP426 (now withdrawn) had a concept of
source_url metadata, which almost satisfied the requirement.
[1] is therefore a revival of source_url, with a different storage format
to allow for additional use cases.
Looking forward to reading your comments.
Best regards,
-sbi
[1] https://github.com/python/peps/pull/1009
[2] https://github.com/pypa/pip/issues/609
[3] https://discuss.python.org/t/pip-freeze-vcs-urls-and-pep-517-feat-editable-…
Hey all,
You may have seen some hub hub around psycopg2 and no longer shipping binary wheels by default [1][2] (and in fact using psycopg2-binary if you want wheels), and I wanted to bring it up here because it demonstrates a problem area with the current state of packaging in Python:
There is no good way for a new package to specify that it provides what another package would provide, and setuptools currently checks that all distributions are found before running the console scripts (so if a console script has a setup.py that depends on psycopg2 and you install psycopg2-binary it fails) [3]
So currently if you pip install psycopg2-binary and then install a project that uses psycopg2 as a dependency it will install psycopg2 over top of psycopg2-binary.
The author of psycopg2 stopped distributing binaries for psycopg2 because of issues with the version of SSL that Python was compiled for/what was used by psycopg2 and it causing all kinds of issues.
I don't have a proposal or a fix, but this is going to be an issue not just for psycopg2 but also for other projects that potentially distribute wheels that are built against a different version of OpenSSL.
I see two things that should get some thought:
1. How to have a package provide for another package (there are keywords but AFAIK they are currently ignored by pip)
2. How to handle/deal with shared libraries that are not versioned
Thanks,
Bert
[1]: https://github.com/psycopg/psycopg2/issues/674 <https://github.com/psycopg/psycopg2/issues/674>
[2]: https://github.com/psycopg/psycopg2/issues/883 <https://github.com/psycopg/psycopg2/issues/883>
[3]: https://github.com/zalando/patroni/issues/1021#issuecomment-480202590 <https://github.com/zalando/patroni/issues/1021#issuecomment-480202590>
Is there a contact for the list owner so that people like this can get removed?
> Begin forwarded message:
>
> From: eysz7x(a)python-org.link
> Subject: Re: [Distutils] psycopg2/psycopg2-binary
> Date: April 6, 2019 at 15:34:29 MDT
> To: xistence(a)0x58.com
>
>
>
>
> Thanks for emailing me! No, I haven’t been hacked :)
>
> I signed up for a spam filtering service called BitBounce. To deliver your email to my inbox, please click the link below and pay the small Bitcoin fee. Thanks!
>
> $0.05 to deliver your email.
>
> We’ve never met — I’ll pay your fee.
>
> <https://bitbounce.com/pay_bitbounce_fee/3742583551>
> I know you — Add me to your whitelist.
>
> <https://bitbounce.com/whitelist/request_access/3014729?email_address=xisten…>
>
>
> BitBounce <https://bitbounce.com/?ref=bitbounce> is powered by > the Credo <https://bitbounce.com/credo> cryptocurrency
>
> I’m from a business — > what are my delivery options <https://business.bitbounce.com/>
> BitBounce and Credo are > transacted through CredoEx <https://credoex.com/?ref=bitbounce>
> Made by Turing Technology Inc. in San Mateo, California Sign Up for BitBounce <https://bitbounce.com/?ref=bitbounce>
Hi folks,
Frazer McLean noticed that even though the version parsing regex in
PEP 440 Appendix B was explicitly restricted to ASCII digits, the
`is_canonical` regex was more permissive and nominally allowed
arbitrary Unicode [Nd] characters.
The restrictive interpretation was the correct one (and reflects what
tools actually support), so I've merged Frazer's change at
https://github.com/python/peps/commit/1dd991e9001ffea6b41e9a2cd3a6549dd984b…
to fix the omission and update the `is_canonical` regex to be
consistent with the version parsing one.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia