Provide a python api + PyPI package for q

[fizyk]

Use if name == '__main__' for standard command line usage in script.
This would also allow to test the code itself.

[harelba]

Acked. I have plans for it in the near future.

Thanks

[hannes-brt]

+1

[webmaven]

👍

[harelba]

I see there is high demand for it :)

I'll try to make room for it so it wlil go into the upcoming 1.5.0 version (due in a couple of weeks).

I'll update here.

Harel

[harelba]

I've created an API which will allow working with q from inside python programs. I'll upload an alpha version to the master branch in the coming day or two.

Hopefully, it'll be good enough to be released as part of the upcoming 1.5.0 version. Once it is good enough, I'll also finish the job of making qtextasdata a proper pypi module so it can be installed through pip.

Any comments regarding it will be most appreciated.

[harelba]

Alpha branch of the python api has been committed to https://github.com/harelba/q/tree/expose-as-python-api.

Hopefully, I'll find a good way to make this a proper pypi package without needing to replace all the installation code. If I manage to do that, then this addition will come out in the coming 1.5.0 version.

Any input would be helpful and appreciated.

Harel

[harelba]

Forgot to write - The readme file of the branch contains the required information about the API.

[webmaven]

What if you split the q python package into a pypi installable package (although q is taken), and then made it a dependency of the system installable q-text-as-data?

[harelba]

Writing the same response here, for other people as well.

That's what probably I'll do eventually if there is no other option, but that's exactly what I wanted to prevent - Doing that would require fixing all the installation code for homebrew/rpm/debian/arch, and I would really like to find a good way to work around doing that, since it will postpone the time the API support will be released.

[webmaven]

OK, how about this then:

Split the q python package into a pypi installable package, and then pull it in here as a git submodule, rather than as a system package or Python dependency?

[harelba]

Let's decide that all the discussions regarding this subject will continue here on this issue's comments.

@webmaven , this might be a good idea regardless of the issue at hand, but it won't prevent the need to rewrite all installations.

One of the complications in it being a python module is that you need pip to be installed on the user's machine. Another idea would be to have the module code reside in some private directory which only q (the command line interface) would know about.

I'm starting to think that rewriting the installations would be a must. In that case, I would prefer to try again to provided a binary compiled version of q. However, when I tried it in the past it "almost worked". Everything worked well, but there were some GLIBC versioning issues with old Linux machines.

If you have experience with compiling python for old linux machines using PyInstalled, any information about it would be great.

Harel

[webmaven]

A python distributable package is just a package directory (or module) nested in another directory with a bunch of extra stuff, which can easily be ignored.

So if the package is in it's own repo, I think that making it a submodule of this one should prevent most rewriting. It certainly won't need to be pip installed.

[harelba]

Maybe I'm missing a part of your point, @webmaven, but there's another implicit requirement for this - The need not to duplicate any code. I don't want the executable "q" to contain the same code of the qtextasdata python module. Does what you're suggesting cover this?

[webmaven]

A git submodule is basically transcluded, you need ever only edit the python code once, in either location, but you would be publishing it twice, as both an exectuable command and as an installable python module. Which is your concern?

[harelba]

Thanks, I believe I see your point. I'll take a look at it.

[harelba]

As part of the 1.5.0 release that I've released today, the q command line now uses a full-blown python module and API behind the scenes.

Exposing it as a PyPI python module will be a separate phase, after reviews by the community of the new API.

You can take a look at the python API here. Any comments would be most appreciated.

[Flimm]

I haven't looked over it in detail, but I would recommend going ahead and putting on Pypi before someone else grabs the name q.

... too late, looks like someone already has grabbed the name q.

[webmaven]

@Flimm:

... too late, looks like someone already has grabbed the name q.

Yes, I noted that upthread: #24 (comment)

[webmaven]

Any suggestions for a different package name?

[bitti]

qlib? But the confusion with Qt related libs might be too great. So qapi?

[webmaven]

qball, quirk, qlever, qore, etc.?