Add setuptools as alternative for distutils

[lerrua]

Hi @svanoort

Thanks for made pyresttest, it's really useful to us.

I'm trying to contribute and resolve the issue #117, but I guess the setuptools to debug a python package and to distributing is most interesting than distutils. (example: python setup.py develop)

So, I opened this Pull Request for the pyresttest committers to use setuptools as alternative.

[]s

[svanoort-jenkins]

Can one of the admins verify this patch?

[svanoort]

Hi @lerrua,
I'm glad you guys at catarse are finding PyRestTest helpful, and certainly welcome any assistance you have to offer! As far as testing for the issue goes: I find a lot of the time it's easiest just to invoke the pyrsttest/resttest.py script directly from a clone when investigating issues (versus doing a pip install).

I'm going to apologize in advance if it's a while before this can be merged though -- I need to finish fixing the issues with the installer test framework (captured in #120 ). The reason is that it's very easy to break package installation without good test coverage (has bitten the project a couple times already). While setuptools is definitely more modern than distutils, we need to make sure there aren't regressions. Hope that's not an issue?

Cheers!
Sam

[lerrua]

@svanoort great, I believe we will not have problems with setuptools (most people use). With setup.py develop we can install a package, put pdb and debug in runtime it help so much.

If you need help to write tests or continuous tests builds, i'll glad to help.

Anyway, I think people asked you before but why you don't use travis or circleCI to CI? It's free, great outputs, people can see everything about the build etc.

[svanoort]

@lerrua I'd definitely welcome any help you've got to offer on PyRestTest -- it's got an ambitious roadmap through to version 2.0 (including some major restructuring internally to support more advanced features)! Milestones/Roadmap.

Right now, 100% the best places to help are support (issues coming in with questions have been a major time cost) -- #117 is a really good starting point. Also, work on Python 3 compatibility for #98. Important note: All in-flight work on Python 3 compatibility should base off of branch feature-refactor-parsing -- this incorporates major changes across 3 related epics. There is a docker environment for testing python 3, with instructions for use in the building.md.

I'm not too worried about getting the CI work set up (probably an afternoon's work one weekend), there's just several larger things in progress to wrap up first. My employer is the main open source contributor to Jenkins, so I'm very familiar with it and the advanced features (which are used here) -- that's why it's preferred vs. Travis CI here.

[svanoort-jenkins]

Can one of the admins verify this patch?

[svanoort-jenkins]

Can one of the admins verify this patch?