Another part of this that I figured out the other day is what you're hitting with pycurl. However, I think that the best solution here is to link the pycurl binaries from the local system so that we get https working.

ln -s /usr/lib64/python2.7/site-packages/pycurl* .

That takes care of the pycurl issues better than installing from PYPI with pip.

There's another reason why the pycurl from pypi might not be ideal. I see this during installation:

src/pycurl.c:151:4: warning: #warning "libcurl was compiled with SSL support, but configure could not determine which " "library was used; thus no SSL crypto locking callbacks will be set, which may " "cause random crashes on SSL requests" [-Wcpp]

I'll update the patch to use system pycurl instead.

Yeah, that was the other issue I was trying to get at. Apologies for not being clear about that.

I understand why you split up the requirements file, but I really don't want to go down that route. We can either tell people to do the requirements.txt twice or specify another 'pip install pycurl'

However, neither of those options solves the actual problem and I suspect that https urlgrabber won't work with pycurl installed with pip

Running the command twice doesn't work. It seems that packages are first extracted and built somewhere (all of them) and only after that installed. Because urlgrabber build process fails, none of the packages get installed. We can either have it in a separate file, or remove it completely and put it into readme. Or use system urlgrabber.

OK, I didn't go back and try this again - was running off memory. With the ssl issues, I think that we can work around this for the time being with symlinks or --system-site-packages and rely on the system-installed pycurl (and maybe urlgrabber).

In the long run, I'm wondering if porting to requests is the best solution but that's farther down the road :)

Why did you change this? the runtask.py in the root repository works just fine.

As a side note, if libtaskotron is installed with pip -e, you can just use 'runtask' because the setup.py adds a binary to the path.

In the previous line, you cloned task-rpmlint. And then you execute runtask.py in the same CWD. Which means you have cloned task-rpmlint into a checkout of libtaskotron. Which, I assumed, is a mistake. My directory structure looks like this:

taskotron/
taskotron/libtaskotron
taskotron/task-rpmlint

Thus I assumed that CWD for those examples should be taskotron and adjusted the paths accordingly.

I agree that the best approach here is to install libtaskotron with pip install -e, maybe we should make it the default approach in our readme and adjust the example accordingly?

It doesn't matter much where task-rpmlint is cloned, as long as the yaml file's path is correct. I tend to clone things like you did and start the runner from the libtaskotron repo. My commands end up looking like:

python runtask.py -e <envr> -a <arch> ../task-rpmlint/rpmlint.yml

I just figured it was easier to describe as checking out task-rpmlint in the libtaskotron dir

Thanks for adding the example, that helps. I still don't understand why 'python libtaskotron/runtask.py' is better than 'runtask' or 'python runtask.py', though.

this should probably be removed. I've recently (in the last day or two) had this commented out and have been 'installing' pycurl via symlink like koji. IMHO, this is a better short term solution.

I'll adjust that.