pmxbot IRC Log Viewer

[01:24:10] <stochastix> I seem to be getting ssl errors when using pip right now, is anyone else having this problem?

[01:31:08] <stochastix> Im teamviewed into someone having the same issue. Is pip borked right now?

[01:44:24] <ngoldbaum> stochastix: https://pypi.org/help/#tls-deprecation ?

[01:44:40] <ngoldbaum> have you been able to use it recently?

[01:44:46] <ngoldbaum> or first time you've tried to use it in a while?

[01:44:48] <stochastix> I havent tried recently

[01:44:52] <stochastix> Yea

[01:45:05] <ngoldbaum> you need to move to modern TLS

[01:45:20] <ngoldbaum> pypi's CDN dropped support for tls 1.1 and 1.0

[01:49:08] <stochastix> Im in Arch, they are using TLS 1.0?

[01:49:15] <stochastix> I somehow doubt that

[01:49:39] <stochastix> Or is it a python library issue?

[01:51:48] <njs> stochastix: maybe paste the actual error?

[01:56:58] <stochastix> I cleared my .cache/pip and it seems to be working again

[08:20:15] <akaIDIOT> what's the way to make tox / pip work in an environment where python.org / pypi.org are inaccessible and a dependency uses setup_requires?

[08:20:30] <akaIDIOT> we have a local mirror in the network that works fine, pip finds it

[08:21:03] <akaIDIOT> but as soon as it calls setup.py egg_info setuptools attempts to download the setup_requires and complains that pypi.org is unavailable

[08:21:35] <akaIDIOT> seems like pip should forward its config to setuptools there, but there might be a reason that's not done?

[08:22:20] <akaIDIOT> building things with tox, so calling pip before deps are installed is weird too

[08:22:26] <akaIDIOT> is there a default way to go about this?

[08:24:35] <akaIDIOT> adding a find_links to [easy_install] in setup.cfg doesn't help (think the command is called in a temp dir)

[10:24:12] <undu> !logs

[10:24:12] <pmxbot> http://kafka.dcpython.org/channel/pypa

[11:26:33] <mgedmin> akaIDIOT: the workaround is to figure out in advance what setup_requires are used where and pip install them before pip installing the thing with the setup_requires

[11:27:23] <mgedmin> I hope in the future PEP 518 can replace/augment setup_requires so this is no longer a problem

[11:27:35] <mgedmin> assuming all the packages that today use setup_requires add pyproject.toml files

[12:20:34] <fred1807> Why this pip install is failing? https://paste.debian.net/plain/1023270

[12:21:59] <mgedmin> it looks like your setuptools is too old?

[12:22:16] <mgedmin> what does 'apt policy python3-setuptools' say?

[12:22:40] <mgedmin> (python3-pkg-resources actually, but it'll be the same version as python3-setuptools)

[12:24:21] <mgedmin> you need at least version 8.0 (released in 2014) to support PEP 440 (which defines ~= for version comparison)

[12:25:17] <akaIDIOT> mgedmin: hmm, was afraid of that, requires me to basically bypass the dependency installation by tox and do that manually :(

[12:25:36] <mgedmin> skipping to a workaround: create a virtualenv, pip install -U pip setuptools inside that virtualenv, then pip install what you need

[12:26:05] <mgedmin> for tox you could pip install --user virtualenv and add ~/.local/bin to the beginning of your $PATH

[12:26:30] <mgedmin> (virtualenv bundles pip and setuptools, so if you've got a new virtualenv, all envs created with it will use new pip/setuptools)

[12:26:53] <akaIDIOT> though tox *creates* the venv

[12:26:55] <akaIDIOT> on a build server

[12:27:07] <mgedmin> yes, but tox will use the virtualenv from your $PATH to create the virtualenv

[12:28:35] <mgedmin> so if you upgrade virtualenv and then ask tox to recreate its envs, things should start working

[12:28:35] <akaIDIOT> think I'm missing the point, don't see how that would fix the venv tox will use to install the deps

[12:28:45] <akaIDIOT> the build env is not persistent

[12:28:54] <mgedmin> <mgedmin> (virtualenv bundles pip and setuptools, so if you've got a new virtualenv, all envs created with it will use new

[12:28:57] <mgedmin> pip/setuptools)

[12:29:10] <akaIDIOT> though pip/setuptools are not the problem

[12:29:24] <mgedmin> "virtualenv" here refers to the package, not the directory-with-bin/python-etc

[12:29:56] <mgedmin> akaIDIOT: whoops sorry I thought I was talking to fred1807

[12:30:07] <akaIDIOT> ghe :D

[12:30:17] <akaIDIOT> I was such confuzzled for a moment

[12:30:17] <mgedmin> yeah, setup_requires is an annoying problem

[12:30:59] <mgedmin> akaIDIOT: https://github.com/mgedmin/zodbbrowser/blob/master/tox.ini#L9-L25 is what I had to do to avoid easy_install

[12:31:09] <akaIDIOT> simply the fact that pip calls setuptools there without propagating the index url causes issues for me

[12:31:12] <akaIDIOT> let's see

[12:33:00] <akaIDIOT> I dont understand the actual solution

[12:33:14] <akaIDIOT> what causes the installation of persistent there?

[12:33:48] <mgedmin> in my tox.ini? I added 'persistent' to deps, so tox will run pip install persistent before it runs pip install -e zodbbrowser[test], which depends on BTrees, which have a setup_requires=['persistent']

[12:34:09] <akaIDIOT> ow my problem is *within* deps

[12:34:18] <mgedmin> that is harder

[12:34:30] <akaIDIOT> my project depends on weasyprint, which int turn depends on cairocffi, which setup_requires cffi

[12:35:09] <mgedmin> but if you express your deps via setup.py's install_requires (or extras_require), then you can do what I did

[12:35:12] <akaIDIOT> I could move all the deps to manual pip install commands before running the tests or something

[12:35:18] <mgedmin> ... or that

[12:35:36] <akaIDIOT> the setup.py defines deps, which are locked by requirements.txt for tox builds

[12:36:00] <akaIDIOT> hence working around the tox thing, would've hoped there was a neater solution for this

[12:36:12] <akaIDIOT> but thanks for the spam, lemme see if I can fix this

[12:42:15] <akaIDIOT> well, that could work, only need to create some switching magic for py2 vs py3

[12:42:27] <akaIDIOT> or choose this to be the moment to ditch py2 >:)

[12:44:15] <mgedmin> oh right fabric doesn't support py3 yet

[12:44:47] <Wooble> mgedmin: and don't think pycharm doesn't remind me of that every time I try to edit my fabfile for an otherwise-py3 project. )

[12:44:57] <Wooble> "hey! you forgot to install fabric!"

[12:45:25] <mgedmin> I don't have many fabfiles left, I could rewrite them all into ansible ...

[14:38:30] <wooster> can someone tell me where i'm going wrong with my long_description markdown here please? https://pypi.org/project/gdpr_check/

[14:41:14] <wooster> i did just like https://github.com/di/markdown-description-example/blob/master/setup.py

[14:47:01] <ngoldbaum> wooster: do you have the latest version of setuptools and twine installed?

[14:47:03] <mgedmin> wooster: note that GDPR applies to EU citizens _even when they connect from a non-EU IP address_

[14:47:07] <wooster> setuptools yes

[14:47:10] <ngoldbaum> did you upload your package with twine?

[14:47:15] <ngoldbaum> i think you need to use twine

[14:47:20] <wooster> twine yes

[14:47:25] <wooster> i used setup.py to upload

[14:47:33] <ngoldbaum> i think you need to use twine to upload

[14:47:45] <ngoldbaum> using setup.py to upload is deprecated so it doesn't get new features like this iirc

[14:48:41] <wooster> twine tells me the API moved

[14:49:10] <ngoldbaum> what's the error you see?

[14:49:40] <wooster> ok using twine worked

[14:49:42] <wooster> thanks!

[14:50:18] <mgedmin> hey what setuptools version is needed for long_description_content_type?

[14:50:36] <mgedmin> because 39.1.0, which seems to be the latest one, complains about it when I run python setup.py --long-description

[14:50:49] <ngoldbaum> TIL that's even a thing

[15:16:06] <Wooble> mgedmin: as I understand it they have to be physically located in europe at the time the data is collected but of course a proxy could be involved. (IANAL, and hopefully also not responsible for compliance at work)

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 4th of May, 2018