Feature #14217
closed
Expose RUBY_PATCHLEVEL_STR or similar with patch level info for rc/preview as a constant
Added by shayonj (Shayon Mukherjee) over 6 years ago.
Updated 18 days ago.
Description
Problem¶
When ruby is in release candidate or preview, RUBY_PATCHLEVEL
is -1
. Without parsing RUBY_DESCRIPTION
, its hard to tell using constant the right and absolute ruby version.
Proposal¶
Expose RUBY_PATCHLEVEL_STR
as a constant, just like RUBY_VERSION
or RUBY_PATCHLEVEL
. So that, we can know the right ruby version, especially when its in preview or release candidate. This is also helpful when using gems that rely on RUBY_PATCHLEVEL
and RUBY_VERSION
to serve the right experience. Example: Bundler, which validates gem installation by making sure right ruby is installed. Currently, we cannot install gems using 2.5.0preview1.
Your Ruby version is 2.5.0, but your Gemfile specified 2.5.0preview1
This can be handled in bundler through some different wokraround, but I think by exposing RUBY_PATCHLEVEL_STR
, it will be helpful in building the appropriate solutions.
I am happy to a patch/create a Github PR, if this sounds like a good option.
- Subject changed from Expose RUBY_PATCHLEVEL_STR as a constant to Expose RUBY_PATCHLEVEL_STR or similar with patch level info for rc/preview as a constant
I can't say whether the name that you haved picked for the constant is good or bad - it seems a
bit long. But I agree on the general problem mentioned, so I am all for more fine-tuned control.
The ruby core team may have decide on the name perhaps.
Currently, we cannot install gems using 2.5.0preview1.
I think there is another bug report that is vaguely related, e. g. a hardcoded ruby version
to 2.5.0 preview1, for ruby 2.4.3, so you may have a point there. Strictly speaking, the
release for 2.4.3 would be invalid if an internal gem depends on ANOTHER ruby version
that is HIGHER than the released ruby. :)
Agreed that it may appear as long. I chose this as a proposal, because it was already defined and was simpler to expose. Example:
From 8cef26bbdf314dccf1d36984a49c35f0a815bbea Mon Sep 17 00:00:00 2001
From: Shayon Mukherjee <dev@shayon.me>
Date: Thu, 21 Dec 2017 16:51:13 -0800
Subject: [PATCH] Introduce RUBY_PATCHLEVEL_STR constant
---
version.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/version.c b/version.c
index 4c7b1abb40..6c66c12eb0 100644
--- a/version.c
+++ b/version.c
@@ -30,6 +30,7 @@ const char ruby_version[] = RUBY_VERSION;
const char ruby_release_date[] = RUBY_RELEASE_DATE;
const char ruby_platform[] = RUBY_PLATFORM;
const int ruby_patchlevel = RUBY_PATCHLEVEL;
+const char ruby_patchlevel_str[] = RUBY_PATCHLEVEL_STR;
const char ruby_description[] = RUBY_DESCRIPTION;
const char ruby_copyright[] = RUBY_COPYRIGHT;
const char ruby_engine[] = "ruby";
@@ -59,6 +60,12 @@ Init_version(void)
* the patchlevel will be -1
*/
rb_define_global_const("RUBY_PATCHLEVEL", MKINT(patchlevel));
+ /*
+ * The patchlevel string for this ruby. If this is a development build
+ * of ruby the patchlevel string will be dev otherwise the respective
+ * rc or preview candidate.
+ */
+ rb_define_global_const("RUBY_PATCHLEVEL_STR", MKSTR(patchlevel_str));
/*
* The SVN revision for this ruby.
*/
--
2.15.1
IMO, RUBY_PATCHLEVEL_STR
still makes sense since it differentiates it from RUBY_PATCHLEVEL
, but at the same time I am not too big on the idea of having the the type of the return value in a constant name. I am more than happy to go with a different name. Few others I had in mind were RUBY_PATCHNAME
and RUBY_PATCHLEVEL_NAME
.
Is it possible to get any updates on this approach? :)
- Description updated (diff)
Could you elaborate how you want to use it?
- Status changed from Open to Closed
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0