Improve install instructions for pip

[felipedau]

I noticed a few things on the install instructions that could be improved. If these sound like a good idea, I can make a PR with the changes.

List dependencies not installable with pip

Some dependencies can only be installed with the package manager. I was able to install txtorcon on a fresh Debian 8 only after installing:

# apt-get install -y gcc libssl-dev python-dev

I have only found mentions to some of these dependencies in .travis.yml and Dockerfile. I think it would be good to have these in the docs.

Add instructions using pip on the README

The instructions on the README only use apt-get. If using stretch/main users will get txtorcon 0.18, but if using jessie/main they will get 0.11! I think it would be good to add instructions using pip too.

These instructions should also include the requirements mentioned above.

Thanks!

[meejah]

Yeah, these sound great, thanks! It might be better to say "build-essential" instead of (or in addition to?) just "gcc", too in the apt-get line.

At some point I chopped the README way down to "minimal", but it seems to have crept back up ;) so yeah proper "pip" install instructions would be good; there is still a whole "installing" document so just brief ones in the README please :)

txtorcon is in jessie-backports, so any "real" users should probably be using that. I don't know what version you get in there...

[felipedau]

Yeah, these sound great, thanks! It might be better to say "build-essential" instead of (or in addition to?) just "gcc", too in the apt-get line.

Hmm, right. Sounds good.

At some point I chopped the README way down to "minimal", but it seems to have crept back up ;) so yeah proper "pip" install instructions would be good; there is still a whole "installing" document so just brief ones in the README please :)

Okay!

txtorcon is in jessie-backports, so any "real" users should probably be using that. I don't know what version you get in there...

Oh, that's better! 0.17 is in there. What do you mean by "real"? They would have to manually set to use jessie-backports, right?

[meejah]

Maybe "real" was a bad choice of word.

Really, I would expect most things to be installed via pip into a virtualenv.

The usefulness of txtorcon being packaged in Debian is mostly for other "packaged in Debian" things (e.g. OONI?). So, for example, if unMessage were to be packaged in Debian it could take advantage of this (obviously, the txtorcon package would have to be upgraded to 0.19.1+). I wouldn't recommend using system-packaged Python dependencies except for other system-packaged things (or, sometimes, for "hard to pip-install" things like Qt or other GUI bindings).

Some admins prefer to only install via packaged things, so for them too i guess "debian packaged txtorcon" is useful as well -- but in general all OS-packaged libs lag behind a fair amount.

[meejah]

p.s. the reason I mention it in the README is just that it's a really easy way to get "some" txtorcon installed if you want to try it out via "twistd" (etc).

[felipedau]

Really, I would expect most things to be installed via pip into a virtualenv.

I couldn't agree more.

The usefulness of txtorcon being packaged in Debian is mostly for other "packaged in Debian" things (e.g. OONI?). So, for example, if unMessage were to be packaged in Debian it could take advantage of this (obviously, the txtorcon package would have to be upgraded to 0.19.1+). I wouldn't recommend using system-packaged Python dependencies except for other system-packaged things (or, sometimes, for "hard to pip-install" things like Qt or other GUI bindings).

Some admins prefer to only install via packaged things, so for them too i guess "debian packaged txtorcon" is useful as well -- but in general all OS-packaged libs lag behind a fair amount.

I see. And I will probably have to do that for a better Whonix integration at some point, I guess.

I'm pretty unhappy with how hard it is to keep software updated in the official repos. I think that if users have to be instructed to customize some setting to get a "not so old" version, then it would be easier to just ask them to use a custom repo the devs control so they can always get the latest versions.

The problem is that there must be a good way to verify the signing key and not everyone can provide a repo for their stuff :/

Anyway, I think this is probably one of those discussions that will never get solved.

p.s. the reason I mention it in the README is just that it's a really easy way to get "some" txtorcon installed if you want to try it out via "twistd" (etc).

Right. I just suggested that because people that are lazy like me and want to go straight to a "quick start" section would appreciate having it in the README.

[meejah]

I see. And I will probably have to do that for a better Whonix integration at some point, I guess.

Usually not. Finding someone interested in unmessage who is already doing packaging seems like "the" way to do it.

So, yes, there are trade-offs for and against these things, but if you're an admin keeping lots of boxes alive, having to worry about which repos everyone needs would get tedious -- so 'trusting Debian', turning on automatic updates etc is great. But then you pay for this by having generally older software.

[felipedau]

Usually not. Finding someone interested in unmessage who is already doing packaging seems like "the" way to do it.

That's a great idea! Thanks!

So, yes, there are trade-offs for and against these things, but if you're an admin keeping lots of boxes alive, having to worry about which repos everyone needs would get tedious -- so 'trusting Debian', turning on automatic updates etc is great. But then you pay for this by having generally older software.

Indeed. I wonder if having a package on the official repos that provides a custom signing key, sets a custom repo and downloads the real package is too wrong/evil to ever be approved :P

[meejah]

I wonder if having a package on the official repos that provides a custom signing key, sets a custom repo and downloads the real package is too wrong/evil to ever be approved :P

There's some precedent for this. There is (or was) a "flash-nonfree" package that would download the proprietary flash player for you and install it. There's also "torbrowser-launcher" that downloads Tor Browser Bundle, checks sigs, etc.

...but, I think it defeats the purpose of the system package manager somewhat. Of course, so does TBB because it has its own update mechanism. :/

Pragmatically: distributions aren't going away, and by necessity provide "old" software -- and in fact, this is part of their advantage! You get tested software that for-sure works together. So, if you want your thing "in Debian", the right way is to get a Debian developer interested in packaging it. They will do timely updates, put it in the appropriate "backports" repo, etc. so it won't end up lagging behind too far. Users get easy install and unattended-upgrades but then you can't push out a release to users in 2 days ...

I guess txtorcon is lagging a little in jessie-backports, but perhaps that's because stretch is "just about" to be released? (And stretch has January's 0.18.0).

[felipedau]

Pragmatically: distributions aren't going away, and by necessity provide "old" software -- and in fact, this is part of their advantage! You get tested software that for-sure works together. So, if you want your thing "in Debian", the right way is to get a Debian developer interested in packaging it. They will do timely updates, put it in the appropriate "backports" repo, etc. so it won't end up lagging behind too far. Users get easy install and unattended-upgrades but then you can't push out a release to users in 2 days ...

Hmm got it. I have to agree :P

I guess txtorcon is lagging a little in jessie-backports, but perhaps that's because stretch is "just about" to be released? (And stretch has January's 0.18.0).

You are probably right. I think I've read something similar about other apps too.