Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create a version function #297

Open
11 of 15 tasks
oubiwann opened this issue Nov 17, 2016 · 8 comments · May be fixed by #299
Open
11 of 15 tasks

Create a version function #297

oubiwann opened this issue Nov 17, 2016 · 8 comments · May be fixed by #299
Assignees
@oubiwann
Labels
enhancement status:in-progress
Milestone
Backlog

Comments

@oubiwann
Copy link
Member

oubiwann commented Nov 17, 2016 •
edited

In the past several years, I'ver iterated on several different forms of a version function in LFE -- sometimes just a string, sometimes a data structure. Most recent work with LFE Docker images has made this even more desirable -- but not at a third-party library level, rather something that really should be part of LFE. It would be nice for developers who have started up an LFE VM to call a version function and get a data structure that could easily be used to 1) get all the information they want about versions, and 2) extract just the bits that they are interested in.

My long-standing needs of this sort of function are for programmatic uses (determining what's available for a given version, conditionals that make decisions based on this, etc.). However, this feature might be even more used from LFE REPLs.

I have a version of just such a function that I will port to Erlang and submit a PR for.

Desired features:

  • contains versions for not only LFE but other major parts of OTP, if present
  • is easily extensible -- something that community libraries could use, adding their own version numbers to
  • is usable by all supported versions of Erlang
  • is accessible from LFE apps by just calling (version)
  • is accessible from the LFE REPL by just calling (version)
  • optionally takes a key argument to return only one part of the version data structure, e.g., (version 'lfe)
  • memoize top-level function so that expensive os:cmd calls aren't repeated
  • update help/usage output
  • add example usage in examples directory
  • update shell docs
  • update lfe_guide docs

Review feedback tasks:

  • remove the macro for version/0/1, no need for it (per @rvirding; @oubiwann would like to keep it ... waiting on final word from Robert)
  • don't use the process dictionary; use an ets table owned by the init process with a global name, like lfe-version-info
  • normalize all the OTP versions to have the same format, not mixed like "R16B3" and "19.1" (will make comparisons easier)
  • generate the LFE version at compile time and use that in code
@oubiwann oubiwann mentioned this issue Nov 17, 2016
Open
@yurrriq
Copy link
Contributor

yurrriq commented Nov 17, 2016

👍 what is the scope of this function? Just LFE? Loaded applications? Modules? I could see utility in any of those. We could potentially do cool stuff conditionally based on versions à la preprocessor macros.

@oubiwann
Copy link
Member Author

Current output:

lfe> (version)
(#(os
   "Linux liberator 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux")
 #(kernel #(4 4 0))
 #(otp "18")
 #(emulator "7.3")
 #(system
   "Erlang/OTP 18 [erts-7.3] [source] [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false]")
 #(driver "3.3")
 #(nif "2.10")
 #(lfe "1.3-dev")
 #(rebar "rebar 2.6.0 18 20151024_031110 No VCS info available.")
 #(rebar3 "rebar 3.3.2 on Erlang/OTP 18 Erts 7.3"))

If relx or mix were installed, their versions would show up too. Should work on *BSD, *NIX, and Windows.

@oubiwann
Copy link
Member Author

App key lookup output:

lfe> (version 'lfe)
"1.3-dev"
lfe> (version 'otp)
"18"

@oubiwann
Copy link
Member Author

Okay, this is ready for review -- creating PR ...

@oubiwann oubiwann linked a pull request Nov 17, 2016 that will close this issue
Draft
12 tasks
@oubiwann
Copy link
Member Author

@yurrriq In answer to your question:

  • the call to version is just something to return a data structure
  • however, some of the supporting functions are exported, since they would be useful
  • in particular, I have great need of the exported function app_version (which does need to load the requested app in order to checks the app's version) -- this function exists in LFE form in the rebar3 lfe version plugin ... that plugin's logic would almost go away once this ticket/PR is accepted into LFE ...

Currently there is no utility function here to extract vsn from modules -- only from .app/.app.src. There's no reason it couldn't be added here, though. It wouldn't be useful for anything usable by the top-level version function, since that's for apps/tools/os. But once this feature is merged, I'd be +1 for adding related utility functions ... thus the name of this module :-) (lfe_system_info).

@yurrriq
Copy link
Contributor

yurrriq commented Nov 17, 2016

I see. The examples above were very helpful 😄. 👍 to adding other utility functions later. #299 looks good to me.

@oubiwann
Copy link
Member Author

Sweet.

@oubiwann oubiwann self-assigned this May 7, 2019
@oubiwann oubiwann added this to the 1.3.1 milestone May 7, 2019
@oubiwann
Copy link
Member Author

oubiwann commented May 8, 2019

Rebased on latest branches/fixes (some of which are pending review).

@oubiwann oubiwann modified the milestones: 1.3.1, 2.1 Oct 14, 2020
@oubiwann oubiwann modified the milestones: 2.1, Backlog Jan 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@oubiwann oubiwann

Labels
enhancement status:in-progress
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

Add version functions to LFE oubiwann/lfe
2 participants
@oubiwann @yurrriq