crystal-lang
pcre package dependency is disappearing
PCRE has been deprecated for a long time and it's starting to disappear from package repositories (it's no longer available in Debian Unstable and Testing, for example: https://tracker.debian.org/pkg/pcre3).
Crystal has been defaulting to use PCRE2 since 1.8 and the PCRE2 library has been a depdency of the package builds ever since. We still had PCRE as a dependency though to make it easy to fall back to the old library if necessary. Now it seems to be time to drop this dependency because modern distro versions cannot provide it anymore.
We could also keep it available for older package repositories, though I'm not quite sure how that could be done (especially for DEB packages).
I have prepared a patch to remove pcre1 dependencies from the latest crystal1.15 package in OBS: https://build.opensuse.org/request/show/1248056
I wonder, should we have regex as an optional feature in the compiler? once pcre1 disappears bootstrapping crystal will become harder. We can't be ready for everything to disappear, but maybe having a compiler with less dependencies will help long term maintenance and portability.
This seems like a tangent. But in what sence does it get harder? Old compiler versions still need pcre1 and I don't suppose we'll remove regex from older versions. Newer compiler versions can use pcre2 which continues to be available.
Yes, tangent.
Old compiler versions still need pcre1 and I don't suppose we'll remove regex from older versions.
No. But maybe it will be worth back porting. I don't recall if the regex are actually used in the compiler itself.
Newer compiler versions can use pcre2 which continues to be available.
Until pcre3 is a thing.
@bcardiff do you mean you want to write your own regular expression engine in pure Crystal? 😁
Or have the compiler not use regular expressions to help with forward compilation? That's doable, though we allow regex in macros, so we'll still need an engine.
Unless we're talking about a bootstrap compiler? 🤔
I believe the compiler uses pcre primarily for evaluating regular expressions in the macro language (StringLiteral#=~, #gsub, #scan). Not sure if there are other uses. But I'd presume the compiler should in theory work without regular expression support unless a codebase uses a specific feature such as regex macros.
So we could consider making this an optional feature which you can opt-out of for simplicity.
Lazy-loading libpcre2 only when needed could also be an option.
So a somewhat "bootstrap" compiler with disabled extra features (regex, tools, gc, ...). It could be a bit faster to compile. Sounds great 👍
I think we can close this. We have dropped the pcre1 from our packages.
The bootstrap compiler idea is nice, but not part of this issue. We can continue the discussion about that elsewhere.