Log file Viewer

[05:14:42] <domenkozar> dstufft: I have a branch for python updates for Nix package manager that builds packages, I wonder if it would be helpful to test out new pip release before it's released by building our set

[05:14:55] <domenkozar> it has py 2.7, 3.3, 3.4, 3.5 and pypy

[05:15:00] <domenkozar> with openstack and all

[10:41:54] <mgedmin> what's this? https://dpaste.de/t6qm

[10:43:33] <mgedmin> this happens also if I manually nuke .tox and retry. python 2.7 only.

[11:52:55] <s3lext> Installing pillow on fedora ? ValueError: jpeg is required unless explicitly disabled using --disable-jpeg, aborting

[11:53:00] <s3lext> what package am i missing

[11:59:12] <s3lext> anyhelp guys ?

[12:05:11] <s3lext> I can install it through python-pillow rpm

[12:05:14] <s3lext> but do not want to

[12:07:50] <mgedmin> libjpeg-devel or something similar

[12:08:13] <mgedmin> check out the build dependencies of the python-pillow rpm and install those packages

[12:08:24] <mgedmin> on debian it would be apt-get build-dep; on fedora I'venodiea

[12:11:11] <s3lext> hmm

[12:11:14] <s3lext> the problem is that package

[12:11:20] <s3lext> python-pillow has no requriements

[12:15:25] <s3lext> libjpeg-turbo

[12:15:31] <mgedmin> s3lext, here I googled this for you: https://pillow.readthedocs.org/en/latest/installation.html#building-on-linux

[12:15:43] <mgedmin> a list of packages you want for fedora

[12:20:43] <s3lext> mgedmin: i've repoqueried

[12:20:51] <s3lext> sudo dnf repoquery --requires python-pillow

[12:20:57] <s3lext> which gave libjpeg.so.62

[12:21:01] <s3lext> then http://rpmfind.net/linux/rpm2html/search.php?query=libjpeg.so.62&submit=Search+...

[12:21:03] <s3lext> :D

[12:21:05] <s3lext> walla

[12:21:10] <s3lext> for those who wonder...

[12:21:33] <mgedmin> you also want the -devel package

[12:21:41] <s3lext> it worked

[12:21:45] <s3lext> without devel

[12:36:48] <ngaio> Is there any reason a linux-only application written PyQt should be available on PyPi? Or is PyPi really meant for library code?

[12:38:23] <dstufft> ngaio: there's no reason you can't use PyPI for that. Generally I think library code is going to be the most popular usage, but applications are totally supported and reasonable to distribute through there

[12:38:56] <ngaio> dstufft, does it make sense even for a PyQt application? I ask because PyQt is not hosted on PyPi

[12:38:57] <mgedmin> "Environment :: X11 Applications :: Qt" is a perfectly valid trove classifier ;)

[12:41:03] <dstufft> ngaio: What makes sense is going to be pretty specific to what you're trying to do. If it were me I'd try to get PyQT to publish to PyPI (looks like they have aname on PyPI, just not any uploaded files - https://pypi.python.org/pypi/PyQt4) and then upload it to PyPI

[12:43:59] <mgedmin> would it make sense to publish pygobject on PyPI? you can't publish linux binaries yet, and the soruce of pygobject uses autotools rather than setup.py for building

[12:44:30] <mgedmin> plus it needs stuff like gir typelibs for glib/gtk+/pango/etc. to be useful, and those are distributed separately

[12:44:46] <mgedmin> plus you need actual glib/gtk+/pango libraries for your app to run

[12:44:50] <ngaio> I must admit I'm totally overwhelmed by the complex interface between what my Python application needs in setup.py, and what Linux distros need to package the application into deb/rpm etc. It's all very complex and difficult to figure out!

[12:45:08] <mgedmin> having a gui app on pypi is nice, tho

[12:45:26] <mgedmin> you can tell users to 'sudo apt-get install python-pyqt' or whatever, and then 'pip install yourapp' on top of that

[12:45:42] <mgedmin> it's not as nice as providing a PPA, but maybe better than letting them clone your app from github

[12:46:41] <dstufft> mgedmin: I know very little about pygobject to be able to accurately say

[12:47:41] <dstufft> ngaio: If you don't care about ``pip install <your application>`` working, then you can totally ignore PyPI. That's really the only reason to care

[12:47:49] <ngaio> From what I can gather, it seems the requirements.txt acts as the ultimate "master" to determine what dependencies are needed for an application to run, and that deb/rpm/other package tools can use that to build up the dependencies needed for their packages? Is that correct?

[12:48:27] <dstufft> ngaio: requirements.txt isn't really related to a particular package, it's more of a way to recreate a specific environment. setup.py and install_requires are the packaging metadata files

[12:50:31] <ngaio> dstufft, so the setup.py is pretty much always the ultimate authority as to what an application needs to run?

[12:51:18] <dstufft> yea

[12:51:34] <dstufft> https://caremad.io/2013/07/setup-vs-requirement/ might be helpful

[12:52:14] <ngaio> thanks, I saw that earlier today and wondered if it was still current. I'm glad it is

[12:52:34] <dstufft> I say "applciation" and "library" in there, but what I really mean is "instance" and "reusable thingy that I don't have a great name for"

[13:01:13] <ngaio> thanks dstufft, I'll carefully reread that now. On another matter, my application is called Rapid Photo Downloader. If it goes up on PyPi (I'd like that), is this the correct entry I should be putting in setup.py: packages = ['rapid-photo-downloader'].

[13:02:00] <dstufft> ngaio: assuming you're talking about the name of the PyPI entry, you'll want to use name="rapid-photo-downloader"

[13:03:02] <ngaio> dstufft, oh okay. Would it ever make sense for the packages entry to be different?

[13:03:41] <ngaio> I seem to recall reading somewhere that hyphens are either illegal or frowned upon in the packages entry

[13:03:45] <dstufft> the packages entry is what the ``import`` is on disk, so since import doens't support -, you'd want it to be like rapid_photo_downloader or whatever

[13:04:01] <dstufft> you might also find packaging.python.org useful

[13:05:03] <ngaio> yes, of course you're right - I'm sorry to bother you with elementary questions.

[13:06:10] <dstufft> ngaio: it's no worries :)

[13:06:12] <ngaio> I'm just a bit overwhelmed by the fact that Debian say don't use wheels, as they're not needed, and wheels being important in PyPi, etc.!

[13:43:21] <ionelmc> ngaio: where do they say that?!

[13:47:29] <Wooble> They probably also think pip isn't needed because why would you want something they didn't package for the OS installed into your system python?

[14:03:51] <ngaio> ionelmc, https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html

[14:04:26] <ngaio> they also have a forked pip, but it seems they're trying to narrow the gap between their pip and the regular pip

[14:14:35] <ionelmc> there's some misunderstanding of purpose imo

[14:15:15] <ionelmc> the fact that you can zipimport a wheel is a merge conjecture and not the intended general use for them

[14:21:11] <ngaio> do you mean misconjecture?

[22:45:48] <luhkevin> I'm on OS X El Capitan and when I try to install virtualenv via pip, I get: 'IOError: [Errno 1] Operation not permitted: '/bin/virtualenv'

[22:46:13] <luhkevin> Any ideas? Why is the install script trying to install to /bin?

[23:34:46] <glassresistor> so i've been thinking about how pip handles revoking and/or changing the content of package versions

[23:35:33] <glassresistor> right now authors can do it whenever they want and often times the failures don't happen at install time but rather runtime of tests or worse runtime of users

[23:36:49] <glassresistor> I'm curious if the potential of making revokes or changes to a package version so that on install users can see that packages have changed or even potentially warning users that there local systems package version has change/been removed on pypi