There are some things here that is unclear and making me uneasy:

• There is no deprecation here. Seems to have dropped SafeYAML entirely. What happens to downstream plugins that uses SafeYAML?
• The module name Jekyll::YAML is ambiguous. When used without the Jekyll:: id, it is unclear whether we are calling the Ruby stdlib module (::YAML) or the one under Jekyll.
• There is inconsistent use of read_opts: kwarg based on the diff. Why the inconsistency?
• Lastly, the commit author and PR author seem to be different ids. Are they both the same person?

should I add some deprecation warnings so they can start using the Jekyll wrapper?

Yes. That's the way it is usually done. We need to give time to downstream plugins to make changes as necessary since we are only going to bump the minor version in the next release.

IMHO, The correct way to go about doing this is to:

export wrapper method(s) > intercept calls to 'SafeYAML' > issue deprecation warnings > forward to associated wrapper

Without deprecation warnings and interception-forwarding, we might as well use Psych directly but that'll happen only with
Jekyll 5.0. However, now is not the time for a major version bump.

I also found some cases where SafeYAML was loading files without read options from configuration, specially when it's used on commands, how would you handle that?

My recommendation would be to not use the read_opts configuration for YAML loading at all. It is meant for File.read calls.

Note that there are two comments above this. (in case you don't see them in your email notification.)

@fauno Based on the errors reported in the check_run, and in sync with @DirtyF's decision to add this to the v5.0 milestone, I'm deferring this for the future. The maintainers will revisit this if SafeYAML become unusable before that.

In the interim, you're free to continue improving the code in this branch.

Just a heads up, Gentoo is going to remove Jekyll packages because of the dependency on safe_yaml (which doesn't work with recent Ruby versions):
https://marc.info/?l=gentoo-dev&m=168015966309355&w=2

AFAICS Debian's Jekyll package includes this PR as a patch, 0016-Drop-usage-of-safe_yaml.patch in http://deb.debian.org/debian/pool/main/j/jekyll/jekyll_4.3.1+dfsg-1.debian.tar.xz because they no longer support Ruby versions 2.x either.

Direct link to debian's patch: https://salsa.debian.org/ruby-team/jekyll/-/blob/master/debian/patches/0016-Drop-usage-of-safe_yaml.patch

Thank you for letting us know, @ulm and @Flowdalic.

Hey, I'm quite busy at the moment but I can carve some time in May

No hurry, @fauno.
We haven't started developing towards v5.0 yet.

No hurry, @fauno. We haven't started developing towards v5.0 yet.

@ashmaroli safe_yaml is beyond dead, Debian packaging was apparantly forced to apply this pull request here before being merged (which is not common practice and signals urgency) and the Gentoo deadline for remove is 2023-04-30 at the moment, so "no hurry" is not realistic here. Maybe it can be moved, but we have a fire here already, not smoke, not potential future smoke. What am I missing?

CC @ulm @fauno

@hartwork I understand the situation with safe_yaml being dead an all. Ruby 2.7 (the last in Ruby 2.x) itself reaches EOL tomorrow (31/03/2023). That means, the Ruby ecosystem is at a cusp of two major versions of the runtime language. Maintainers have to decide whether to continue supporting older versions and move ahead entirely.

All that said, Jekyll 4.x cannot yeet safe_yaml out to maintain backwards-compatibility with plugins out in the wild. It would have been possible gradually if Psych and SafeYAML did not differ significantly from each other. (My experience with various versions of Psych wasn't exactly smooth).

Gentoo Linux will have to forego packaging Jekyll n co, for the time being.

@ashmaroli if external plugins remain using safe_yaml does that mean that yekyll itself has to keep using it? I don't understand why that would be the case, e.g. Debian would be in big trouble now after patching it out, else. Please help me understand what I'm missing.

if external plugins remain using safe_yaml does that mean that yekyll itself has to keep using it? I don't understand why that would be the case...

@hartwork Jekyll follows Semantic Versioning protocol and therefore cannot remove existing runtime dependencies under the assumption that downstream plugins with requirements jekyll ~> 4.0 could be using the dependencies directly and therefore, is implicitly part of the public API. For example, a plugin calling SafeYAML.load_file(filename) is valid usage especially since the latest release Jekyll 4.3.x itself uses the exact incantation.
The way forward is to either first ship a release which deprecates using SafeYAML directly, and then remove the dependency in a future major release;; or remove the dependency directly in the very next major release.

Regarding the state of the Debian package, that would be upto respective project maintainers to worry about. Its their responsibility to have adequate tests to check if an incoming patch has an effect on existing compatibility.

@hartwork Jekyll follows Semantic Versioning protocol and therefore cannot remove existing runtime dependencies under the assumption that downstream plugins with requirements jekyll ~> 4.0 could be using the dependencies directly and therefore, is implicitly part of the public API.

@ashmaroli just for the record, I would disagree on that assessment in any other project. It's the responsibility of plug-in code to explicitly depend on all direct dependencies and not rely on other software to pull them in. So that would just be a build system bug in those plugins, nothing more. Debian seems to agree with me on that.

Alright @hartwork I [agree to disagree].
However, Jekyll 4.x will not be doing away with SafeYAML. At max, it will only be deprecated.

Note that this PR breaks the minimal-mistakes theme, because Psych by default does not accept YAML aliases (but it can be asked to by using aliases: true). For more details, see this Debian bug report.

@svillemot thanks! I added your patch on the PR with your authorship :)