Align/merge w upcoming LIRC python APII?

[leamas]

Hi! I'm the upstream lirc maintainer. The plan is that next release, 0.9.5, will contain a "official" python API. We have rather well-defined parts for the send/command parts (send codes etc.), but the API for receiving data is yet to be defined.

Found this package by coincidence. I really love the @listen_for decorator, it solves the most important usecase. It's something to build on, really.

If building from this, I'm interested in using the existing lirc_client lib : it provides two objects RawConnnection(socket path) and Connection(lircrrc_file, socket_path) with interface

• readline()
• fileno()
• has_data()
• close()

A RawConnection readline() returns the untranslated code string, the Connection the translated one.

Now, my idea is to align "your" stuff with the existing "backend" and also add a @new listen_for_any_key decorator. With this, we should have send, async read and also "normal" read interfaces in place.

The current state of the python stuff is at https://sourceforge.net/projects/lirc/, look for the 'python' branch. It's an unstable feature branch, rebased form time to time.

Thoughts?

[pylover]

It's an honor for me. What should we do ? please guide me.

[pylover]

Where should i develop the stuff? the sf fork, and or this github repo?

[leamas]

It's an honor for me. What should we do ? please guide me

I'm honored as well! Welcome on-board!

I think we could (and should) develop this in our own repos for now. The aligning would then be about changing your "backend", basically the cython code, to instead use the upcoming LIRC python api. And, of course, check/patch/rewrite the existing API as required. It's also about expanding and documenting the async API.

Which lirc version have you been using so far? The best would be if you could clone the sf repo and build it. It's pretty straight-forward. After building you will find API docs which I think are more or less readable. Look into Modules, python bindings (left pane).

In the python branch there is also a script tools/lirctool. It can be used to simulate events, which is handy in this context. There are notes in CONTRIBUTE.md how to run things without installing them, you certainly want to do that.

I'm actually not sure about how ti distribute the lirc API. My gut reaction has been to include it in the packaged versions, but after trying to set up a virtualenv from this I'm about to reconsider. In the end, this might actually just be one or two pypi packages, dunno. Let's see where it goes.

Again: Thoughts?

--alec

[leamas]

https://github.com/leamas/python-lirc-api

This is exactly the same code as in sourceforge (built from symlinks), exported as a pip package for now.

[pylover]

Thanks, it's great

So, for the first. i'll align my library to work with the official lirc backend,

[pylover]

Oh, my bad. I forgot to thank you about the github repo.

[leamas]

Don't be too quick - I'm about to kill the github repo ;) . I've deemed it unmaintainable.

Instead I have updated the core lirc build system to also create a source package. The idea is that regular users should have the core python API installed by default. Developers could use the source package to install lirc in virtual environments etc. Bottom line: you need to buld lirc to get access to the new packages. Have you setup this process?

Another issue is the async_client.py file I attached to issue [#3]. As for now, it's included i the core lirc parts. But perhaps it could just be part of your package (or something similar), and we drop it from lirc for now?

Thoughts?

--alec

[pylover]

OK, of-course.

I'll try to build the new lirc from source forge repo, and align my library to work with it's python api.

[leamas]

I have pushed some commits to the python branch, making a better split between the python stuff and the rest.

Please let me know if you run into any problem building! It's basically a no-brainer, but as always there is a need for dependencies.

We still need to decide on the async_client.py file. Should it go into LIRC, and you build on that? Or do you prefer to build against LircdConnection and RawConnection, coding the rest yourself? Thoughts?

The API is shaping up. I think it's feature complete, perhaps even too big (async_client). The docs seems also reasonable. The big missing thing is tests (no test-driver developent here... ). Also need to review the error handling.

[pylover]

Thanks a lot,

I'll try to build the environment at the weekend, which are Thursday & Friday here.

But i already have built it on my rpi, i think it's not hard.

Sorry for my english.

[leamas]

We all speak the universal geek language Bad Englisch (tm). And we certainly doesn't apologize for that :)

I have pushed a new version of the python branch. It's basically ready to be merged into master. I have found and killed a few bugs, so you probably want to use that. It's rebased.

[pylover]

I think it's ok to make it as a python package which loads shared objects from PATH, and it's good to available as a pypi package, including it in official C deploy is putting python developers in conflict state.

So, their can set the ENV variables before activating their virtualenvs to point the path to load the lirc shared object.

Thoughts?

[pylover]

Including C in python is usual, but the vise-versa, i don't think so.

[pylover]

And making it to work in editable install mode pip install -e . and or python setup.py develop.

[leamas]

It's kind of complicated. Some points:

• The package is useless (more or less) without a local lirc installation.
• The package contains lirc.config, which is a direct result of how ./configure was run.
• The package contains native code linked to lirc.

Taken together, my gut feeling is that some kind of "base" package should be an integral part of t he lirc distribution. However, it should be kept as small as possible, and that's why I'm not really sure that the async_client should be part of it.

It's still possible to publish the base package on pypi, with some reservations for lirc.config + native code. But better then would IMHO be to publish one or more add-ons; some variant of your package comes to mind.

Nothing is carved in stone, for sure...

[pylover]

You think very elegant and i appreciate that.

But this situation is verry popular in python. Raising runtime error to install some libraries, then users of each platform doing it by their favorite package managers, like yum, apt, pacman, homebruw, *.pkg and etc...

Another issue: the sharedobject with name: _client.cpython-35m-x86_64-linux-gnu.so is not good, because it will putted in dist-packages directly after built and install.

so adding a lirc prefix is recommended

[leamas]

You obviously know more about pypi packaging. Could you come up with a proposed patch to setup.py?

Note that the "real" library installed by 'make install' just is _client.so... Edit: And it's installed in /usr/lib/python/site-packages/lirc on most linuxes; dist-packages is a debian anomaly.Anyway, isn't the package directory sufficient as prefix?

[pylover]

The _client....so file is not a clear name, so users cannot find what is this file in their site-packages directory, and may be removing because it's a binary file, i obviously delete such kind of files, on production env.

[leamas]

OK, this makes my point clear: the _client.so file should be part og the base package.

What's different to many python packages is that lirc has working channels to all major distributions: it's packaged more or less everywhere. This means that users can just install the lirc package and ti just works. We should IMHO probably stick to that for the compiled stuff.

If you as user of a virtualenv wants to change the linker load path (not $PATH) it's of course possible. But then you are on your own, right?

[pylover]

Yes, of-course.

But i don't mean to move the shared object to official lib.I just suggesting to change it's name to help users to understand it's related to the lirc library.

At, all i think also it's ok to handle the python api along-side of the core, this helps compatibility.

Ok. it's clear.

But still something is not clear for me, Where should i code? this repo, your given github repo, and or wherever you saying?

[pylover]

Another issue with your code is PEP8. which i already added a ticket about that: https://sourceforge.net/p/lirc/tickets/260/

[leamas]

My suggestion: this repo. Basically, I handle "my" repo, and you handle your. Users installs lirc and your package on top of it (pointers to this package in the lirc release notes , website etc.).

I'm more than open to move code/and or functionality from lirc to your repo if we deem it suitable. The LIRC parts feel like a little to big.

But the overall perspective is the elegant decorator-based listening syntax on top of the proposed lirc API...

[pylover]

So good, I completely agree with you.

[leamas]

That said, if you have one or more patches to improve "my" setup.py, Iwould be happy for that... seems lika you have ideas?

[pylover]

Of-course, sure. it's my pleasure

[pylover]

@leamas , Sorry for late, I'm back to fix this issue. Is there any update/change on official API, which should i aware about that?

[pylover]

There is not package named "lirc" in pypi, It's ok to register this name a-s-a-p.because in your setup.py the package name is "lirc".