Log file Viewer

[02:02:09] <burzos> Is there anyway to get `pip install <some-archive>` to execute something other than setup.py; like possibly a bash script?

[02:02:35] <burzos> I'm trying to get pip to install something weird where I need to not run python during the installation itself.

[02:03:37] <burzos> Essentially the postinstall script for my package has a requirement that python not be running when it runs.

[02:30:13] <dstufft> burzos: No

[02:33:16] <burzos> dstufft: Any ideas on how to handle a situation like this?

[02:33:45] <burzos> I have a whl I want to install, but after the wheel installs I need to run a postinstall script that requires python to not be running otherwise.

[02:34:16] <dstufft> I don't have a good answer for you besides try to figure out how to make it not have that requirement

[02:34:34] <dstufft> but post install steps don't really work well

[02:34:52] <dstufft> e.g. it's impossible to have them with wheels at all

[02:35:08] <burzos> This package is weird and I don't see a way around it.

[02:35:40] <burzos> Running the postinstall script from a bash installer works fine.

[02:35:53] <burzos> But then it's confusing that the requirements.txt file only kind of finishes the setup.

[02:36:33] <dstufft> I mean, wheels flat out don't have any code that executes at all during install

[02:36:46] <dstufft> it's just unzipping and moving files into place

[02:37:04] <burzos> dstufft: I've taken care of that by adding the wheel as dependency in a setup.py, then doing some postinstall stuff there using a subclass

[02:37:22] <dstufft> that's not a post install script, that's a post-build script

[02:37:39] <dstufft> e.g. it only occurs when the wheel is built, not when the wheel is installed

[02:38:14] <burzos> cmdclass['install'] refers to a build thing?

[02:38:16] <burzos> That doesn't seem right.

[02:38:55] <burzos> Doing the equivalent of this http://stackoverflow.com/questions/17806485/execute-a-python-script-post-install-using-distutils-setuptools

[02:38:59] <dstufft> it's a bit complicated, setup.py comes from a time before wheels were a thing, when you'd have sdist as a source package that you could do ``setup.py install`` (which is conceptually similar to ``make install``)

[02:39:11] <dstufft> now we have wheels, and a wheel does not have a setup.py at all

[02:39:28] <dstufft> so you can still do post-install steps when installing from a sdist

[02:39:33] <dstufft> but *not* when installing from a wheel

[02:39:43] <dstufft> because a wheel does not have any code that executes at install time

[02:39:50] <dstufft> a wheel doesn't even have a setup.py

[02:39:53] <burzos> Well sure, I just have a directory with a setup.py.

[02:40:04] <burzos> In that setup.py I have the wheel I want to install as a depedency.

[02:40:19] <burzos> Then I do a pip install on that directory

[02:40:44] <dstufft> pip will implicitly build a wheel and cache it and reuse that built wheel for future installations fwiw

[11:09:47] <mattt> hi all, i'm building a virtualenv on two hosts -- on one it includes argparse and setuptools in the virtualenv, in the other it doesn't

[11:11:03] <mattt> is this simply down to virtualenv versions or some external factor?

[11:14:31] <mgedmin> argparse is in the stdlib

[11:14:35] <mgedmin> since python2.7

[11:14:39] <mgedmin> what python version do you use?

[11:14:48] <mattt> both are using python 2.7, the systems are the same

[11:15:00] <mgedmin> could be something to do with virtualenv versions

[11:15:08] <mattt> yeah i'm going through the changelog now

[11:15:18] <mgedmin> run 'virtualenv --version' and see

[11:15:23] <mgedmin> if it's the same, look elsewhere ;)

[11:15:45] <mgedmin> still, no setuptools? I thought you had to ask with a special --no-isntall-setuptools arg when creating

[11:16:15] <mattt> mgedmin: Requirement already satisfied (use --upgrade to upgrade): setuptools>=1.0 in ./keystone_venv/lib/python2.7/site-packages (from cryptography>=1.0->keystone)

[11:16:38] <mattt> oh wait that's not the same error as the argparse one, sorry :P

[11:16:44] <mattt> Requirement already satisfied (use --upgrade to upgrade): argparse in /usr/lib/python2.7 (from oslo.config>=3.2.0->keystone)

[11:17:35] <mattt> so where i'm seeing that it's running virtualenv 14.0.5, and where it includes argparse is 13.1.2

[12:28:40] <AlecTaylor> hi

[12:28:59] <AlecTaylor> Inside a virtualenv, why is `pip install .` working differently to `python setup.py install`?

[12:29:11] <AlecTaylor> (data files aren't being copied across in `pip install .`)

[12:30:54] <mgedmin> hard to say without seeing your setup.py

[12:33:38] <AlecTaylor> Deleting the `~/.cache/pip` didn't work

[12:33:44] <AlecTaylor> But `python setup.py bdist_wheel` did

[12:33:50] <AlecTaylor> Now `pip install .` is working again

[12:33:51] <AlecTaylor> Good

[13:20:03] <mattt> sorry, another idiotic question i'm sure :) i have a python package that if installed puts some wsgi scripts into bin ... however if you build a wheel and then install that, that doesn't happen (only console_scripts are installed)

[13:23:13] <mgedmin> hard to say without seeing your setup.py

[13:24:28] <mattt> mgedmin: https://github.com/openstack/keystone/blob/a55128044f763f5cfe2fdc57c738eaca97636448/setup.py

[13:24:49] <mgedmin> oh, pbr

[13:25:14] <mgedmin> sorry

[13:25:23] <mattt> no worries!

[13:25:31] <mattt> wanted to be sure i wasn't missing something when i was building the wheel

[13:26:23] <mattt> mgedmin: looks like wsgi_scripts may be a pbr thing tho, so thanks for the tip :)

[19:09:57] <natefoo> njs: so i figured i'd try out manylinux1 on my favorite example (psycopg2) and immediately ran into this: https://github.com/psycopg/psycopg2/issues/305

[19:10:24] <natefoo> which raises the question about what to do about things that aren't going to compile nicely on such an old platform

[19:11:30] <natefoo> although i suppose the answer is that if package authors want manylinux1 wheels, they have to make them compile in the manylinux1 image, even if it's painful.

[19:12:45] <natefoo> alternatively, is it reasonable to install a modern postgresql and bundle that libpq? shouldn't make any difference as far as compatibility goes.

[20:19:20] <ngoldbaum> natefoo: wouldn't anaconda have the same issue? how do they work around it?

[20:43:07] <natefoo> ngoldbaum: good question

[20:43:14] <natefoo> i'll look

[21:20:55] <burzos> I'm subclassing setuptools.command.install.install in a setup.py script so I can do some custom stuff. If my crap fails I'd like to return an error such that pip doesn't report that my thing installed successfully. How to do this?