pmxbot IRC Log Viewer

[09:21:55] <FarleyDev> Hi Chaps, quick question for you. Is there a way of globally setting a trusted host, as I want to do some quick local testing. (I will be securing it eventually)

[09:33:06] <ronny> FarleyDev: using a env var ? i think PIP_TRUSTED_HOST or so (please check the docs, im not 100% sure

[10:07:57] <FarleyDev> It might just be where I am trying to look but I can’t see any reference of env vars controlling this.

[14:20:28] <jorgesumle> I tried to install a python module called imapclient with pip, but got an error: https://paste.debian.net/823823/

[14:22:04] <ronny> jorgesumle: it has cryptography as dependency, and that one needs openssl-dev/openssl-devel

[14:22:26] <ronny> jorgesumle: please install the openssl development package and retry

[14:22:54] <jorgesumle> sudo apt-get install openssl-dev, right?

[14:25:17] <jorgesumle> It is installed with "sudo apt-get install python3-openssl"

[14:25:36] <jorgesumle> It is called python3-openssl for Debian-based distros.

[14:26:02] <jorgesumle> ronny: Thanks, I installed that and pip installation worked :)

[14:27:45] <ronny> :)

[17:56:31] <nicksloan> Can someone shed some light (or direct me to some reading) about how the NumPy manylinux wheel works? specifically, it depends on liblapack3, which is not mentioned in pep 513

[17:56:55] <dstufft> nicksloan: either it bundles the .so or it static links

[17:58:59] <nicksloan> ah

[17:59:33] <nicksloan> Developer forgot that he had apt-get installed it first and then removed them. I was surprised that liblapack had been installed via apt

[18:14:16] <ngoldbaum> nicksloan: the wheel static links lapack

[18:14:49] <ngoldbaum> nicksloan: specifically it static links OpenBLAS

[18:14:53] <nicksloan> oh. I was poking around in site-packages and found lapack_lite.so

[18:16:14] <ngoldbaum> i believe this is hte script that does it: https://github.com/matthew-brett/manylinux-builds/blob/master/build_numpies.sh

[18:24:45] <ronny> DanielWHolth: ping

[18:26:49] <DanielWHolth> Ack

[18:27:51] <DanielWHolth> What's up ronny

[18:28:25] <DanielWHolth> Compile any abi3 modules lately?

[18:45:33] <ronny> DanielWHolth: sorry for the delay, in a call with family atm

[18:52:51] <ronny> DanielWHolth: i would like to collaborate on setup.py shims and whell generation tools

[18:54:30] <DanielWHolth> Fantastic. Remind me of your background.

[18:54:58] <ronny> pytest core dev, setuptools exp

[18:55:13] <DanielWHolth> Go ahead and fork bitbucket.org/dholth/enscons

[18:55:39] <ronny> DanielWHolth: i dont want to use scons at al ltho (i want pure python)

[18:56:09] <DanielWHolth> Although SCons is pure python, fair enough.

[18:56:44] <DanielWHolth> It would make sense and would be easy to refactor the code to remove the SCons dependency

[18:57:27] <ronny> DanielWHolth: i also created gumby elf

[18:57:58] <DanielWHolth> Cool

[18:58:54] <DanielWHolth> How do you want to use your proposed system? Like flit but with sdists?

[18:59:31] <ronny> DanielWHolth: i would like to see common shims for setup.py, sdists and wheels

[19:00:01] <ronny> DanielWHolth: (bascially removing the need for setuptools)

[19:00:15] <DanielWHolth> Did you read the 750 lines of enscons?

[19:00:33] <ronny> i skimmed them before, ut i dont recall anymore

[19:02:14] <ronny> currently im explaining my grandmother her email via a hangout call >.<

[19:03:17] <DanielWHolth> Awesome

[19:04:29] <DanielWHolth> Email me. Id be happy to help separate the generate metadata parts of enscons from the run scons part. They are not terribly interdependent.

[19:06:14] <DanielWHolth> Or answer any questions about how setup.py develop etc works.

[19:08:01] <ronny> DanielWHolth: with gumby elf i made a develop command and a install command (both makign wheels then using pip)

[19:08:31] <ronny> DanielWHolth: i would also like to use/spearhead using pyproject.toml for metadata

[19:08:37] <DanielWHolth> Whats a url for that?

[19:09:01] <DanielWHolth> Enscons uses pyproject also

[19:09:41] <ronny> https://github.com/RonnyPfannschmidt/gumby_elf

[19:09:53] <dstufft> someone should send a PR to pip with pyproject.toml support :]

[19:12:27] <ronny> dstufft: also one to setuptools for build_requires in pyproject.toml

[19:12:43] <ronny> its kinda on my todo, but i gotta handle others tuff first

[19:12:56] <dstufft> yea same.

[19:14:42] <ronny> dstufft: i want to handle setuptols first

[19:15:00] <dstufft> what like a [tool.setuptools]build_requiers thing?

[19:15:25] <ronny> dstufft: no, having setuptools be fully pep-518 compliant

[19:15:25] <DanielWHolth> There's some older pr from r collins but it needs much love

[19:15:52] <ronny> dstufft: and then extending on it having tool.setuptools.args instead of arguments to setup

[19:16:20] <dstufft> ah right, I forgot the exact naming

[19:18:23] <DanielWHolth> https://bitbucket.org/dholth/cryptacular/src/tip/setup.py?fileviewer=file-view-default my bootstrap shim. Can easily be extended to install and parse toml first.

[19:34:09] <ronny> DanielWHolth: my plan was to hava a shim that can ship the wheels within a sdist

[19:34:31] <ronny> DanielWHolth: (so setup.py would bea file that adds a few wheel files to sys.path, optionally tells pip to fetch them and is done)

[19:35:12] <ronny> DanielWHolth: one of te reasons being that pip --target is kinda broken ^^

[19:35:19] <DanielWHolth> This is better than distributing the wheel normally?

[19:35:42] <ronny> DanielWHolth: it makes dependency free sdists for distros

[19:35:44] <DanielWHolth> Apparently we have to send a patch to debian

[19:36:06] <ronny> and anyone else uses wheels or the source tree

[19:36:20] <DanielWHolth> You could bundle the build system in each sdist sure.

[19:36:45] <DanielWHolth> Not that different than downloading on demand.

[19:37:25] <ronny> DanielWHolth: bascailly both systems work, and dpeending on the construction of the shim anything works

[19:38:10] <ronny> (i would like to have a different shim in the vcs than the shim that gets shipped wit the wheel

[19:38:29] <ronny> (for example it would be really neat to be able to ship sdists that inclduewheels for manylinux

[19:38:40] <ronny> also bbl this evening, gotta attend to personal matters

[19:45:35] <ronny> re, got another half an hour

[19:50:11] <ronny> DanielWHolth: so yeah, i would like to collaborate on pyproject.toml usage and setup shims

[19:50:19] <ronny> DanielWHolth: as for my tooling, i'd like to make only wheels

[19:50:25] <ronny> and of course share metadata sync code

[19:50:45] <ronny> hmm

[19:50:56] <ronny> dstufft: can a modules/packages loader affect how it sees imports?

[19:51:18] <DanielWHolth> Wheel's repo contains a wscript that also produces wheel without setuptools

[19:51:49] <DanielWHolth> There's a proposal for a wheel pack command.

[19:51:50] <ronny> hmm

[19:52:09] <DanielWHolth> Not difficult

[19:52:10] <ronny> meh for bitbucket tho, i recently sheded myself of my complete bitbucket presence

[19:52:28] <DanielWHolth> Suit yourself

[19:53:17] <ronny> oh, its using waf

[19:54:37] <ronny> DanielWHolth: i already have scripting around making wheels

[19:55:02] <ronny> its mostly shiming out egg info data that im missing and i'd like to share codebases for shiming

[19:55:52] <DanielWHolth> In enscons we cheat by writing requires only to egg info. Rest goes into dist info.

[19:56:54] <DanielWHolth> Pip doesn't need the full metadata during installs.

[19:57:00] <ronny> i see

[19:58:06] <ronny> that also means - the setup.py shim can be a noop for sdists that insert that data before the fact ^^

[19:58:33] <ronny> (i do both normal installs and develop installs via wheels)

[19:58:58] <DanielWHolth> Pip does ask for egginfo to go into a temp directory

[19:59:13] <ronny> thops

[19:59:16] <ronny> eh whops

[19:59:22] <DanielWHolth> How can a develop install via wheel do the right thing

[19:59:26] <ronny> the develop install wheels use local version tags and generate shim python files that refer to the toplevel locations

[19:59:32] <DanielWHolth> Editable install?

[19:59:42] <ronny> so develop installs a set of python files that will load the real toplevels and fix up the packages path

[19:59:56] <ronny> and that in turn makes the develop installed package work correct

[20:00:09] <ronny> and the RECORD only has the shims

[20:00:34] <ronny> so pip uninstall also correectly uninstalls them

[20:01:03] <ronny> (main reason i did that was instant support for correct scripts on all supported platforms

[20:01:11] <ronny> because pip makes them

[20:03:05] <ronny> DanielWHolth: so basically instead of doing the mad setuptools dance, i install a regular set of files, that just fix up __path__ and execfile the real toplevels

[20:07:07] <ronny> hmm, jason is like clockwork, shortly before 10 pm he starts opensource goodness

Log file Viewer

Help | Karma | Search:

#pypa logs for Thursday the 15th of September, 2016