Log file Viewer
#pypa logs for Friday the 27th of February, 2015
[11:33:03] <nanonyme> pf_moore, glyph, poke: https://pypi.python.org/pypi/pypiwin32 ; where do I file bugs about how pypiwin32 is packaged? Uninstalling it fails on Windows. Looks like you guys are marked as package owners
[14:15:13] <nanonyme> This wouldn't obviously happen on Linux as Linux lets you remove files in use by people
[14:26:11] <pf_moore> nanonyne: ah, OK. It's a bug in pip/utils/appdirs.py which uses pywin32 if present. Could you raise a pip bug please? If you want a temporary fix, go to the bottom of that file and remove the bit that uses pywin32 for _get_win_folder.
[14:27:11] <pf_moore> dstufft: see the above comment from nanonyne. I'l be able to fix this but not till after the weekend
[14:27:27] <pf_moore> You mentioned wanting to do a new release - don't know if it's worth getting this in
[14:28:05] <pf_moore> (not many people use pywin32 because there's no official wheels, but obviously some people do...)
[14:28:57] <pf_moore> TBH I think we just remove the pywin32 option and use ctypes always. Can't see why we need 2 options.
[14:29:43] <mathieui> is there a guideline for which kind of software versions should be uploaded to the cheeseshop? (e.g. only stable versions, or anything we want?)
[14:29:43] <dstufft> works for me, I don't know the meaningful difference between pywin32 and ctypes
[14:30:21] <dstufft> mathieui: setuptools/easy_install will install anything you upload by default, so if you have 1.0 and 2.0.dev0 uploaded, it'll install 2.0.dev0
[14:30:51] <dstufft> that's generally not what you want, and because of that, pip (since 1.4) ignores pre-release versiions by default
[14:31:21] <dstufft> unless they are the only thing available to install, or use use the --pre flag, or you use a version specifier that explicitly includes one (like >=1.0.dev0)
[14:32:26] <mathieui> and another question, is there a specific classifier for python sub-versions only (e.g. "Programming Language :: Python :: 3.4 :: Only")
[14:33:46] <dstufft> no, but classifiers aren't strict limits, they are generally designed to be hints rather than explicit constraints
[16:17:58] <nanonyme> How about a package that provided pywin32 API using ctypes as a transitional package if ctypes is supposed to have all of it anyway?
[19:30:37] <_habnabit> dstufft, so i could probably make this better, but here's my current approach for distributing a cffi application: https://github.com/habnabit/passacre/blob/master/setup.py https://github.com/habnabit/passacre/blob/master/passacre/_libpassacre.py
[19:32:29] <_habnabit> actually, now that i think about it, i could split this into two modules: one that has the FFI object, and one that calls verify on that FFI object
[20:00:51] <dstufft> _habnabit: your setup.py isn't going to run if cffi isn't already installed (or rather, it's going to run but without any modules)
[20:02:26] <dstufft> which you wouldn't notice in dev, because when you import the module it's going to get implicitly compiled
[20:02:59] <dstufft> this is part of the reason why my method disables implicit compile all together, because the whole stack is really fragile in ways that are not obvious when you have implicit compiling masking it
[20:11:51] <dstufft> if CFFI isn't availab.e and you run ``setup.py install``, it's going to attempt to import cffi, fail with an importerror, and ext_modules will be []
[20:12:44] <dstufft> if they install as sudo but don't import until you're on a idfferent user, you'll get gcc errors
[20:15:38] <_habnabit> dstufft, so the only thing i need to do to disable implicit compilation is not call ffi.verify() ?
[20:16:27] <dstufft> https://github.com/pyca/cryptography/blob/master/src/cryptography/hazmat/bindings/utils.py#L119-L120
[20:19:49] <_habnabit> i think the way i set this up was relying on pip to install cffi before it actually tried running setup.py for installation of my package
[20:24:41] <dstufft> pip's ordering is a best effort of installing deps before things that depend on them
[20:25:23] <_habnabit> but if my install_requires has cffi in it, how is it possible for my package to be installed first?
[20:26:36] <dstufft> there's a project from Daniel Holth, but I think it's worse than just using setup_requires
[20:28:20] <dstufft> _habnabit: fwiw unless you're having fun going down this rats nest, I suggest copying what cryptography does (documented in my blog post) is the most sanity preserving way. There's a lot of niggly edge cases that we only really found out from having people do things (and there's still more we haven't yet solved, like we apparently break cx_freeze somehow...)
[20:30:02] <dstufft> keywords_with_side_effects is more or less requires if you use setup_requires unless you want something like ``setup.py --version`` to download and compile CFFI
[20:31:04] <dstufft> LazyLibrary you can avoid by splitting up the definition and the actual attempt to load into different modules
[20:31:58] <dstufft> I went that way because I felt like LazyLibrary was less fragile than depending on not having an import that triggers the library loading in the import path of the FFI Verifier object
[20:32:26] <dstufft> the main thing is you just need to make sure that you don't trigger the case that calls load_library when executing setup.py
[20:32:32] <t4nk848> Does anyone know about installing a package from a subdirectory of a git repository?
[20:32:45] <dstufft> which is easy to tell if you are if you disable implicit compilation, because you'll get a runtime error instead of it compiling silently
[20:33:56] <dstufft> I didn't investigate super hard, this cold was originally from pynacl where I used _compile_module
[20:43:41] <_habnabit> dstufft, this kind of stuff makes it kind of hard to sell cffi over writing C extensions or using ctypes ;p
[20:44:38] <dstufft> _habnabit: this is why I've said that it might not be reasonable to recommend CFFI to random programmers yet, even though I think it's superior in general
[20:48:07] <dstufft> _habnabit: armin is on and off working on something better that is inspired by CFFI but which outputs .c files instead of being called by a python API (and then a python API thing to actually load/expose the .so you compile from the .c)
[20:50:59] <dstufft> well not in the linking to myself thing, but in the "yea I'm advising you use a thing which involves all this bullshit you have to do to package it sanely, I'm sorry"
[20:53:33] <dstufft> that would make it so you could do something like ffi.verify("...", lazy=True, compile=False)
[21:07:28] <jlkinsel> hey guys - running into a strange issue - getting pip to install a requirement...it downloads 99% then exits with MemoryError https://gist.github.com/jlk/07b02f01cef197d9301f
[21:07:57] <jlkinsel> this is a brand new VM, this usually has worked in the past (earlier this week)
[22:23:29] <_habnabit> dstufft, er, does setup_requires not pull in transitive dependencies? i have setup_requires=['cffi'] and it didn't install pycparser
[22:24:20] <dstufft> _habnabit: it should, but setup_requires doesn't install things normally, it puts it into your current dir (or .eggs in your cur dir depending on python version)
[22:26:52] <_habnabit> i looked at the log tox wrote out, and it looks like pycparser was installed, but then setup.py failed to import pycparser anyway
[22:40:39] <_habnabit> does tox have an option for teeing command output to the terminal instead of requiring me to dig through to find which log file i want?
[22:47:37] <_habnabit> pjdelport, i have it cranked up to -vvvv but it still only shows me logfile names
[22:54:03] <dstufft> _habnabit: I feel like I've seen this problem before, but I can't recall what it was