setup.py is package manager incompatible

[hasufell]

setup.py is interactive, so it's broken for any distro that your script doesn't automagically detect. Why does it even attempt to do that? Setuptools and distutils are distro-agnostic.

[PeterSurda]

For systems with a package manager, setup.py is a transient solution until native packages are available. The systems I tested setup.py on (about 5 linux distributions and 2 BSD variants) already have the prerequisites (like pyqt, pymsgpack and so on) available as packages, so it would be bad if setup.py tried to install its own variants. Very likely they're available on Gentoo as well.

The interactive query occurs due to optional packages. For example, pyqt is optional and if you want to run pybitmessage as a daemon, you don't need it, even more so because that depends on the X libraries and so on, and you end up installing hundreds of megabytes of stuff you don't need on a server. Without the prompt, the notification about optional dependencies would be lost in a flurry of installation logs, and people would complain to me that it doesn't work.

The solution to this issue are native packages of pybitmessage for each operating system variant, with perhaps one source generating a pybitmessage and pybitmessage-qt binary packages.

[hasufell]

The solution to this issue are native packages of pybitmessage for each operating system variant

I don't understand how one is related to the other. Native packages of pybitmessages are not going to happen on some distros if your setup.py file is broken (as in: interactive). Optional runtime dependencies are not your concern and are handled on the distro side. Just write a proper setuptools/distutils based setup.py file, without guessing what distro packagers need.

[PeterSurda]

I don't understand how one is related to the other.

You're the one insisting that the current setup.py is preventing a proper distro package, and now you say you don't understand that they are related to each other.

[hasufell]

You're the one insisting that the current setup.py is preventing a proper distro package

Yes, because it's interactive. Then you started telling me you want to wait until there are distro packages. But there won't be, because your script is interactive (and as such: PM-incompatible).

You seem to assume all distros out there are binary distros or something. I'm not sure.

[PeterSurda]

I looked at the debian package of msgpack-python (as an example of how they do it), and it looks like it does execute setup.py (through dh). Maybe other distros do that too. I wasn't aware of that. That being said, the prompt only comes up (or should only come up) if there are missing dependencies, in which case the resulting package wouldn't be working correctly anyway. But I'll look at it to see if I can find some solution.

[g1itch]

Hello!

I tried to convey the same idea in comment to commit 636ae17: many distros are using setup.py for package creation or installation and absence of the optional dependency shouldn't cause an interruption of the script execution. Otherwise maintainers will have to write patches to setup.py cutting out that raw_input() call.

pyopencl and numpy surely are the optional dependencies because many users simply do not have the AMD GPU. Furthermore, some distros may consider PyQt as the optional dependency, because pybitmessage may run as a daemon and user may want so.

[PeterSurda]

How about I add a check if it's running interactively like this:

if sys.stdin.isatty():

Would that solve the issues you're having?

[g1itch]

Yes, at least for portage.

[hasufell]

Would that solve the issues you're having?

No.

[PeterSurda]

@hasufell What distro would still cause problems?

[hasufell]

I'm not going to tell you that, because the solution is not more distro-specific hacks. The solution is to remove hacks.

[PeterSurda]

@hasufell The tty check is not distro-specific, and as far as I understand, it fixes the situations where it broke completely before. There still may be cases where it doesn't work correctly, but I haven't heard about any yet. I prioritise based on more common cases I get from feedback. If I remove the prompt completely, it will cause more problems for more users than the scenarios you're describing (and at the moment, hypothesising, since I just added the tty check). I would also happily add an optional parameter to setup.py that will be another way to disable the prompt.

[hasufell]

Your solution is wrong. Your assumptions about what setup.py is for and how distros package python stuff too. This issue is not fixed.

[PeterSurda]

@hasufell You haven't explained what is wrong, other than maybe something somewhere somehow can break for someone. Your original objection that setup.py breaks if it's run non-interactively should have been fixed by the tty check. If it hasn't, let's take that use case and look at it.

I don't really care if someone is offended that I use setup.py in an uncool way or whether their feelings give them a priority over other people's problems. Removing the prompt entirely will break stuff for a wide range of users and create more work for me, since I have to handle the subsequent complaints.

[SoapGentoo]

@PeterSurda I was trying to bump PyBitmessage and also bumped into this. Please change it to not be interactive. Interactive installs are totally unpythonic and occur in no packages maintained or associated with the Python Software Foundation. This is not Windows with interactive installers. Noone in the python community does this.

[PeterSurda]

@SoapGentoo Thank you for your feedback. The problem is, I still need a nicely behaving script for installation that works on as many platforms as possible. If it was possible to add a command line argument when executing setup.py (e.g. "--nice"), that would solve my problem. Unfortunately I haven't figured out a way to do that.

[hasufell]

I still need a nicely behaving script for installation that works on as many platforms as possible

You really don't want to understand, do you? If you remove your platform specific crap, then it works on all platforms. But I guess you know better than the python community and distro packagers.

[PeterSurda]

@hasufell I think it's you who doesn't understand. Besides, there's the obvious counterevidence, if someone really wanted to create a distro package and the prompt was the only thing hindering him, he could just add a patch to his package. But as far as I know this hasn't happened, which proves you wrong. The couple of packages which exist predate the setup.py.

Then there's the more advanced issues, like people being able to install it for daemon mode without having to install pyqt, pyqt not being supported by pip and so on. To these you also provide no solution.

[hasufell]

someone really wanted to create a distro package and the prompt was the only thing hindering him, he could just add a patch to his package

I've packaged pybitmessage for 2 distros. You are wrong. We're just skipping setup.py completely (which is a nuisance, because it's non-standard).

Then there's the more advanced issues, like people being able to install it for daemon mode without having to install pyqt, pyqt not being supported by pip and so on. To these you also provide no solution.

You're applying windows-like "convenience" to a linux ecosystem. Can you guess what is wrong with that approach?

[PeterSurda]

@hasufell

I've packaged pybitmessage for 2 distros.

Why haven't you submitted a patch or announced these packages then? Why are you hiding what you did and instead tell me what I should do?

You are wrong.

Wrong about what? That nobody created a package with setup.py, or that the packager is able to create a patch? Or perhaps a patch isn't needed at all?

You're applying windows-like "convenience" to a linux ecosystem. Can you guess what is wrong with that approach?

I have received tons of reports from people who didn't install bitmessage correctly, because they didn't read the documentation, they didn't follow the instructions, or they just made up crazy stuff. I had to debug all of this. This includes some distro packages. Including the setup.py reduced my work, and anyone is free to patch it or not use it. For some reason you're offended by both of these options. I don't care about you being offended. You haven't contributed anything constructive to this debate. You haven't addressed any of the problems I brought up. @g1itch for example did not only make suggestions but also made a pull request containing bugfixes and improvements.

[SoapGentoo]

@PeterSurda I didn't patch it out because the detectPrereqs function is called in multiple places and I couldn't be bothered to cleanly separate it. Please follow standard python idioms, because it keeps the ecosystem and us sane.

[PeterSurda]

@SoapGentoo Have you tried the v0.6 branch, are you still having problems there?

[PeterSurda]

@SoapGentoo Besides, if you're creating a package, you can skip detectPrereqs altogether as you should be handling that on the package manager level.

[hasufell]

Why haven't you submitted a patch or announced these packages then? Why are you hiding what you did and instead tell me what I should do?

???

https://github.com/Bitmessage/PyBitmessage/issues/331

4 years ago. Get your facts straight.

[PeterSurda]

@hasufell

• the referenced issue requests a removal of ebuildpackage, which I actually did
• the package in the link is for 0.4.4 and doesn't work with the current code (0.6.0 or later), and it doesn't use setup.py. Exactly as I said.

What you could do is simply not execute setup.py, instead add the correct dependencies (optional like dev-python/pyopencl and mandatory like dev-python/msgpack), and add compilation of bitmsghash.so into the existing ebuild. Since now setup.py explains what is missing, this should make it easier for you. You could also try the v0.6 branch and report back if it's still not working, so that when 0.6.3 is released I don't have to deal with this again. Instead, you try to twist it like it's my fault that you haven't done so.

[hasufell]

the referenced issue requests a removal of ebuildpackage, which I actually did

And is the announcement of the package, which you said I didn't do, because I do things in secret.

What you could do is simply not execute setup.py,

I cannot follow. This is exactly what we already do. For all versions of pybitmessage.

[g1itch]

@hasufell if you need a gentoo ebuild you probably can use mine: https://github.com/g1itch/altcoins-overlay/blob/master/net-p2p/pybitmessage/pybitmessage-0.6.2_p20170306.ebuild

With recent code you don't need to patch setup.py

[PeterSurda]

And is the announcement of the package, which you said I didn't do, because I do things in secret.

As you admitted yourself, the linked ebuild has nothing to do with setup.py or this issue at all. It doesn't use setup.py and it doesn't explain why you're having problems with setup.py.

I cannot follow. This is exactly what we already do. For all versions of pybitmessage.

If this is what you're already doing (not using setup.py), then why do you need me to change it and complain it's hindering you? Why don't you amend the existing ebuild for the missing dependencies and bitmsghash.so, now that setup.py explains to you what is missing? And why haven't you reported the results of usingsetup.py from v0.6 branch?

Basically, you want me to do your job and get angry when I refuse.

[PeterSurda]

@g1itch Any chance of adding building bitmshash.so and submitting the changes to the official gentoo repository?

[g1itch]

bitmshash.so is built in setup.py which is used in this ebuild. I have posted my ebuild for 0.6.1 release to bugzilla. To submit to the official repository you must become a maintainer which I can hardly manage.

[PeterSurda]

@g1itch Ok thanks I'll see if I can do something about it.

[hasufell]

@PeterSurda

Basically, you want me to do your job and get angry when I refuse.

No, you really refuse to understand. You're making things hard for every packager out there and even for regular users whose system is not properly catched by your mis-designed automagic checks.

As you admitted yourself, the linked ebuild has nothing to do with setup.py or this issue at all. It doesn't use setup.py and it doesn't explain why you're having problems with setup.py.

You're not really following the argument. We have to reproduce the setuptools/distutils logic you fail to provide, because you deviate from any standard python practice. This also leads to outdated packages as you can see, potentially to it being dropped even.

@g1itch

if you need a gentoo ebuild

Thanks, but I don't use gentoo anymore. And I will drop pybitmessage from exherbo.