Packaging Rearrange

[jamielennox]

I've been looking at packaging this in Fedora for a while and have held off because of the dependencies. I was recently speaking to someone who was in the exact same state for Gentoo and figured that it should be fixed.

The series essentially involves:

• cleaning up the required dependencies, i haven't verified the minimum version number is actually required. I may need to come back and downgrade some of them if possible and there aren't the available versions packaged.
• Adding the documentation and running files to the distributed package.
• Moving the test files into the package. We don't necessarily include the tests in the eventual rpm but we need them to verify the rpm once built. Having tests in the package is also considered the best practice.

[jamielennox]

Hi,

I'd love to get some movement on this - even if it is a flat refusal so i can look at other options. As it stands it is generally wrong and makes it very difficult to package HTTPretty for distributions. Packaging is something we need as HTTPretty becomes a dependency for some high profile projects.

If you disagree with anything then I'm happy to debate it with you.

Thanks,

[gabrielfalcao]

Hi @jamielennox, this pull request looks good besides bringing tests inside of the package.
I can't allow the tests to be moved into the package.
I use an assertion library that modifies the python runtime, impacting on every PyObject* in memory upon import.
Also my test codebase tends to be huge, impacting in the package size.

Is there another solution for you that doesn't involve including the tests?

(You might have been emailed with just part of this comment, I kept hitting enter by mistake)

[jamielennox]

Ok, i've reduced the request to just the dependency changes.

That's an interesting problem with sure that i can't really see a way around. In general it shouldn't matter because nothing would actually import httpretty.tests unless it is running the tests, but i can understand that it might not be worth the risk.

I'll see what i can come up with for a way around that.

Thanks for your help.

[gabrielfalcao]

Thank you for understanding, I'm looking at it now.

Also last night after your email I started a branch to port httpretty to python 3.3, I just don't have any idea on how long it would take, I hope more people contribute.

But also I haven't come up with a porting strategy yet, I ran 2to3 in all python files to have an idea of what the changes will be and it turns out to be more laborious than complicated to accomplish.

[jamielennox]

So i don't think we need to go the whole 2to3 route. That converts the whole code base to 3 code and doesn't necessarily leave you will python2 compatability (in my understanding).

I see you have your own compat.py file - it might we worth looking in to using six instead of this. I've found six covers most cases, but we can continue to add things to compat as needed but six is a very common dependencies for project supporting 2 and 3.

I don't have a lot of time but i can help with the 3 port (as shown by the mailing list thread there is some pressure on me here too).

Let's create a python 3 bug though rather than discussing everything here.

[merwok]

If the tests are in the sdist but not in the final installed code, is it enough for the needs of the rpm package?

[jamielennox]

I'm actually not sure if/how that would change the outcome. Generally when packaging i've just pulled the egg info from PyPi and packaged from that. Does the sdist get published in that fashion that i can easily download it?

If so then sure that's fine, I don't need to install the tests with the code but i need them available to be run at packaging time to verify that the install happened correctly.

[merwok]

I’m not sure about the contents of egg files, since these formats mix up distribution and installation. I think an egg contains the importable code and the packaging metadata, but not all the extra files that one would want in the sdist (licenses, tests, docs...).

I use Debian and know that deb packages are always built from sdists, not eggs, so I did not foresee this issue.

sdists can be downloaded from PyPI as easily as eggs.

[jamielennox]

then yes that would work fine for me. I can easily run python setup.py bdist as part of the packaging process.

@gabrielfalcao: does that perhaps mean that we can push along with some of this cleanup then?

[merwok]

I assume “python setup.py bdist” is a typo for “python setup.py sdist”? I was talking about sdists.

[jamielennox]

@merwok: Actually i'm not sure what i was going for there :)

Yes, if all this is included in the sdist then i can easily build and package from that.

[CyrilRoelandteNovance]

@jamielennox I don't think this patch can be applied on top of master. Could you please re-submit ?

It's quite hard to run tox currently. It should be easier once this patch has been merged. Then, I have a dozen pending patches that bring support for Python 3 that I'd like to push :)

[CyrilRoelandteNovance]

@jamielennox Thank you very much for those patches. I've just pushed them (manually, I don't like GitHub merges since "Merged pull request #xxx" does not make sense outside of GitHub). I've just changed test_recording_calls so that it expects the right version of Tornado - determining what it is at runtime.

One can now build Python 2.7 and 3.3 environments by running tox -epy27 and tox -epy33, this will be useful in a near future.

[jamielennox]

@merwok can you have a look at #141. I think that's the correct way to do the sdist/egg split.