libpcre.so.3 is not on all systems

[dpgeorge]

On my Arch Linux machine import re fails because libpcre.so.3 does not exist. Instead it's libpcre.so.1 (also aliased as libpcre.so).

So should we just change it to load libpcre.so, or try different versions in succession?

[dhylands]

Normally, you would just load libpcre.so and it would be symlinked to the appropriate version.

I've also seen stuff where x.so -> x.so.7 -> x.so.7.4 -> x.so.7.4.3

And most code would be symlinked to x.so and would only include the version if there was a very good reason to.

[pfalcon]

Normally, you would just load libpcre.so and it would be symlinked to the appropriate version.

No, that's not how it works. "3" in libpcre.so.3 is a "major version". It's deemed that if major version changes, the lib grew "completely incompatible" with older (or future) lib version. Apps usually link to such major-specified lib versions. Now pure "libpcre.so" is there for naive ld -lpcre to work (how it comes from user specifying -lpcre but "libpcre.so.3" being recorded in the final executable is under veil of darkness, consider that linker magic). In Debian and derivatives, "libpcre.so" is part of *-dev packages. So yes, the easiest way is to load "libpcre.so", except you can't rely it's there.

[pfalcon]

So, we have a method to try few lib names in turn already (for libc), can use it here too.

@dpgeorge : What actual pcre version your system has? Here it's:

libpcre3:amd64 1:8.31-2ubuntu2

[pfalcon]

Apps usually link to such major-specified lib versions.

e.g.:

$ ldd `which mc`
[]
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc325fd7000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc325dd3000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc325acd000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc3258b3000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007fc325633000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc3253f5000)

[dpgeorge]

It's pcre 8.37-1. The filename is /usr/lib/libpcre.so.1.2.5

I've tested re-pcre/tests_re.py and it works.

BTW, a different solution would be to use builtin ure to implement core re stuff.

[pfalcon]

It's pcre 8.37-1. The filename is /usr/lib/libpcre.so.1.2.5

So, I would imagine, distros would leave shlib versioning to upstream projects. But I may imagine that Debian munged it much enough to patch major version (I assume that's what happens).

BTW, a different solution would be to use builtin ure to implement core re stuff.

Feel free to start re_ure. But when would it have named capture groups? Not soon. Generic forward/backward assertions? Never. So, currently there's just ure for unbloated usage and re_pcre for real-world usage (pcre is already incompatible in minor details to cpython's SRE and apps need patching here and there).

[dpgeorge]

Feel free to start re_ure.

How would you select between the two (if you had both installed)?

[Background: I'm using picoweb to write a simple server and it depends on re. ure is good enough as it is now for my purposes.]

[pfalcon]

How would you select between the two (if you had both installed)?

By using dependency injection pattern. No "library" package should depend on a particular re implementation, it should be select by a top-level user app. I believe that's how it is done already for picoweb/notes-pico, as a proof of concept.

[dpgeorge]

I believe that's how it is done already for picoweb/notes-pico, as a proof of concept.

I don't see that pattern anywhere in your code... picoweb imports re in __init__.py and utils.py.

[pfalcon]

Hello,

On Wed, 03 Jun 2015 07:57:39 -0700
Damien George notifications@github.com wrote:

I believe that's how it is done already for picoweb/notes-pico, as
a proof of concept.

I don't see that pattern anywhere in your code... picoweb imports re
in __init__.py and utils.py.

I don't mean it literally, as a programming "dependency injection"
pattern. I mean meta-pattern, when dependencies are specified at the
top system level, not by intermediate components (and thus entire
system "injects" dependencies into its individual components).

So, both "re_pcre" and "re_ure" distribution packages (Python term)
would provide "re.py". Any intermediate components which would do
"import re" would add neither "re_pcre" nor "re_ure" to list of its
dependencies (to setup.py or requirements.txt), e.g.:
https://github.com/pfalcon/picoweb/blob/master/setup.py

Then selecting which particular implementation to use lies on the
particular top-level (as run by user) application, e.g.:
https://github.com/pfalcon/notes-pico/blob/master/requirements.txt

---

Reply to this email directly or view it on GitHub:
#25 (comment)

Best regards,
Paul mailto:pmiscml@gmail.com

[dpgeorge]

I don't mean it literally, as a programming "dependency injection" pattern. I mean meta-pattern, when dependencies are specified at the top system level

Ok, I see. But then you need a separate installation of libraries for each app.

[pfalcon]

Ok, I see. But then you need a separate installation of libraries for each app.

Well, kinda yes, or at least, it's not possible to install both re_pcre and re_ure at the system level at the same time. But we target small self-contained apps anyway, right? ;-)

[pfalcon]

Ok, any patch coming for this?

[dpgeorge]

Ok, any patch coming for this?

I can do the "try different libs" option. We might eventually want some common code to do this rather than writing it out each time per module.

[pfalcon]

See _libc.py, which has beginning of that, which apparently needs further refactoring to be reusable.