Skip to content

librecad: Update to version 2.2.1.4, fix checkver & autoupdate#17533

Merged
z-Fng merged 1 commit into
ScoopInstaller:masterfrom
SorYoshino:librecad
Apr 5, 2026
Merged

librecad: Update to version 2.2.1.4, fix checkver & autoupdate#17533
z-Fng merged 1 commit into
ScoopInstaller:masterfrom
SorYoshino:librecad

Conversation

@SorYoshino

@SorYoshino SorYoshino commented Apr 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Updates librecad to version 2.2.1.4 and introduces automated registry-based file association for .dxf files.

Changes

  • Update version to 2.2.1.4
  • Improve license field with structured SPDX identifier and URL
  • Add notes to guide users on how to manually register file associations
  • Add suggest for vcredist2022 as a recommended dependency
  • Implement pre_install script to clean up residual installer files ($*, Uninst*, vc_redist*)
  • Introduce post_install and uninstaller scripts:
    • Dynamically generate .reg files by replacing {{librecad_dir}} placeholders with the actual installation path.
    • Support global installation by switching registry hives from HKCU to HKLM.
    • Handle uninstallation by importing the corresponding cleanup registry file.
  • Update checkver to use GitHub API with complex regex to handle MSVC-based asset naming conventions and version tags.
  • Update autoupdate to align with the new asset URL patterns using $matchTag and $matchString.

Testing

The test results are as follows:
┏[ D:\Software\Scoop\Local\apps\scoop\current\bin][ develop ≡]
└─> .\checkver.ps1 -App librecad -Dir 'D:\Temporary\Software\Microsoft\Windows Sandbox\Repositories\Scoop\Buckets\Extras\bucket' -f
librecad: 2.2.1.4 (scoop version is 2.2.1.4)
Forcing autoupdate!
Autoupdating librecad
DEBUG[1775309734] $substitutions (hashtable) -> D:\Software\Scoop\Local\apps\scoop\current\lib\autoupdate.ps1:230:5
DEBUG[1775309734] $substitutions.$matchTag                      v2.2.1.4
DEBUG[1775309734] $substitutions.$cleanVersion                  2214
DEBUG[1775309734] $substitutions.$buildVersion                  4
DEBUG[1775309734] $substitutions.$majorVersion                  2
DEBUG[1775309734] $substitutions.$minorVersion                  2
DEBUG[1775309734] $substitutions.$patchVersion                  1
DEBUG[1775309734] $substitutions.$basename                      LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc.exe
DEBUG[1775309734] $substitutions.$dashVersion                   2-2-1-4
DEBUG[1775309734] $substitutions.$version                       2.2.1.4
DEBUG[1775309734] $substitutions.$dotVersion                    2.2.1.4
DEBUG[1775309734] $substitutions.$url                           https://github.com/LibreCAD/LibreCAD/releases/download/v2.2.1.4/LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc.exe
DEBUG[1775309734] $substitutions.$match1                        2.2.1.4
DEBUG[1775309734] $substitutions.$preReleaseVersion             2.2.1.4
DEBUG[1775309734] $substitutions.$matchTail                     .4
DEBUG[1775309734] $substitutions.$urlNoExt                      https://github.com/LibreCAD/LibreCAD/releases/download/v2.2.1.4/LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc
DEBUG[1775309734] $substitutions.$underscoreVersion             2_2_1_4
DEBUG[1775309734] $substitutions.$matchString                   v2.2.1.3-12-gd1ca469c9
DEBUG[1775309734] $substitutions.$baseurl                       https://github.com/LibreCAD/LibreCAD/releases/download/v2.2.1.4
DEBUG[1775309734] $substitutions.$basenameNoExt                 LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc
DEBUG[1775309734] $substitutions.$matchHead                     2.2.1
DEBUG[1775309734] $hashfile_url = $null -> D:\Software\Scoop\Local\apps\scoop\current\lib\autoupdate.ps1:233:5
DEBUG[1775309736] $jsonpath = $..assets[?(@.browser_download_url == 'https://github.com/LibreCAD/LibreCAD/releases/download/v2.2.1.4/LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc.exe')].digest -> D:\Software\Scoop\Local\apps\scoop\current\lib\autoupdate.ps1:140:5
Found: c6e1ddfa67c24539f3bbb41f5614f6f0d9a30da4c94bfff1c4305ddb9fde5f76 using Github Mode
Writing updated librecad manifest

┏[ D:\Software\Scoop\Local\apps\scoop\current\bin][ develop ≡]
└─> scoop install Unofficial/librecad
Installing 'librecad' (2.2.1.4) [64bit] from 'Unofficial' bucket
Loading LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc.exe from cache.
Checking hash of LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc.exe... OK.
Extracting LibreCAD-v2.2.1.3-12-gd1ca469c9-win64-msvc.exe... Done.
Running pre_install script... Done.
Linking D:\Software\Scoop\Local\apps\librecad\current => D:\Software\Scoop\Local\apps\librecad\2.2.1.4
Creating shim for 'LibreCAD'.
Making D:\Software\Scoop\Local\shims\librecad.exe a GUI binary.
Creating shortcut for LibreCAD (LibreCAD.exe)
Running post_install script... Done.
'librecad' (2.2.1.4) was installed successfully!
Notes
-----
To register file associations, please execute the following command:
reg import "D:\Software\Scoop\Local\apps\librecad\current\install-associations.reg"
-----
'librecad' suggests installing 'extras/vcredist2022'.
  • Use conventional PR title: <manifest-name[@version]|chore>: <general summary of the pull request>
  • I have read the Contributing Guide

Summary by CodeRabbit

Release Notes

  • New Features

    • LibreCAD now associates with .dxf files on Windows, allowing users to open them directly with the application.
  • Chores

    • Updated to version 2.2.1.4.
    • Added Visual C++ 2022 redistributable as a required dependency.
    • Improved Windows installer artifacts.

@coderabbitai

coderabbitai Bot commented Apr 4, 2026

Copy link
Copy Markdown

Walkthrough

Updates LibreCAD Scoop manifest from version 2.2.1.2 to 2.2.1.4, changes license format, updates GitHub release-based checkver/autoupdate configuration, and adds file association registration for .dxf files through PowerShell pre/post-install and registry uninstaller scripts.

Changes

Cohort / File(s) Summary
Manifest Configuration
bucket/librecad.json
Updated version to 2.2.1.4; normalized homepage URL; changed license from string to object format; added registry file handling with pre\_install removal logic, post\_install registry import, and uninstaller registry removal; updated checkver to use GitHub releases JSONPath API with new regex; modified autoupdate templates for release artifacts and removed hash block.
File Association Registry Scripts
scripts/librecad/install-associations.reg, scripts/librecad/uninstall-associations.reg
Added Windows registry scripts to register/unregister .dxf file associations for LibreCAD, configuring ProgID metadata, default icons, and file open commands.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

Suggested labels

review-needed

Suggested reviewers

  • z-Fng

Poem

🐰 From 2.2.1.2 to 4 it did climb,
Registry hops sync in perfect time,
.dxf files now know their home,
PowerShell scripts help them roam,
LibreCAD's associations bloom and shine! ✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main changes: version update to 2.2.1.4 and fixes to checkver and autoupdate, matching the primary objectives.
Description check ✅ Passed The description is comprehensive and well-structured, covering all changes, implementation details, testing results, and confirms adherence to the contributing guidelines with checked boxes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
bucket/librecad.json (1)

33-37: Prefer explicit .reg allowlist over wildcard discovery/import.

Using Get-ChildItem ... '*.reg' (Line 33) and un*.reg imports (Line 49) is broad. An explicit file list is safer and prevents accidental processing if extra registry files are added later.

Recommended refactor
-        "Get-ChildItem -Path \"$bucketsdir\\$bucket\\scripts\\$app\" -Filter '*.reg' -File | ForEach-Object {",
+        "'install-associations', 'uninstall-associations' | ForEach-Object {",
+        "    $regPath = \"$bucketsdir\\$bucket\\scripts\\$app\\$_.reg\"",
+        "    if (!(Test-Path $regPath)) { return }",
-        "    $content = Get-Content -Path $_.FullName -Encoding utf8",
+        "    $content = Get-Content -Path $regPath -Encoding utf8",
         "    if ($global) { $content = $content -replace 'HKEY_CURRENT_USER', 'HKEY_LOCAL_MACHINE' }",
-        "    $content -replace '{{librecad_dir}}', $librecad_dir | Set-Content -Path \"$dir\\$($_.Name)\" -Encoding unicode",
+        "    $content -replace '{{librecad_dir}}', $librecad_dir | Set-Content -Path \"$dir\\$_.reg\" -Encoding unicode",
         "}"

Also applies to: 49-52

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@bucket/librecad.json` around lines 33 - 37, The script currently uses
wildcard discovery (Get-ChildItem -Filter '*.reg') and pattern-based imports
(un*.reg), which is unsafe; replace these with an explicit allowlist of registry
filenames: define an array (e.g., $regAllowlist) containing the exact .reg
filenames to process for the given $bucket/$app, then iterate that array instead
of using Get-ChildItem and use the same allowlist when importing/unregistering
(instead of 'un*.reg'); update places referencing $bucketsdir, $bucket, $app,
$librecad_dir, $dir and the import/unregister logic to read from the explicit
list and handle missing files gracefully.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@bucket/librecad.json`:
- Around line 32-36: The $librecad_dir assignment currently uses -replace
'\\\\','\\\\' which is a no-op; update the code that prepares the registry path
variable ($librecad_dir) to properly escape backslashes by using the
.Replace('\\','\\\\') method (mirroring vscode.json/notepadplusplus.json) so
that when '{{librecad_dir}}' is substituted in the Get-ChildItem/ForEach-Object
block and written via Set-Content the registry string contains doubled
backslashes and is valid.

---

Nitpick comments:
In `@bucket/librecad.json`:
- Around line 33-37: The script currently uses wildcard discovery (Get-ChildItem
-Filter '*.reg') and pattern-based imports (un*.reg), which is unsafe; replace
these with an explicit allowlist of registry filenames: define an array (e.g.,
$regAllowlist) containing the exact .reg filenames to process for the given
$bucket/$app, then iterate that array instead of using Get-ChildItem and use the
same allowlist when importing/unregistering (instead of 'un*.reg'); update
places referencing $bucketsdir, $bucket, $app, $librecad_dir, $dir and the
import/unregister logic to read from the explicit list and handle missing files
gracefully.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4562d875-b146-4140-865c-892134cfee84

📥 Commits

Reviewing files that changed from the base of the PR and between 0288951 and 62d2712.

📒 Files selected for processing (3)
  • bucket/librecad.json
  • scripts/librecad/install-associations.reg
  • scripts/librecad/uninstall-associations.reg

Comment thread bucket/librecad.json
@SorYoshino

Copy link
Copy Markdown
Contributor Author

/verify

@github-actions

github-actions Bot commented Apr 4, 2026

Copy link
Copy Markdown
Contributor

All changes look good.

Wait for review from human collaborators.

librecad

  • Lint
  • Description
  • License
  • Hashes
  • Checkver
  • Autoupdate

Check the full log for details.

@z-Fng z-Fng left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in this PR look good and work as expected. However, I have a few questions:

  1. Phrasing: I believe "For file associations, run:" is more concise and idiomatic.
  2. Wildcards: Specifying the .reg scripts explicitly was clearer. What's the rationale for switching to wildcards?
  3. Process Execution: Why use Start-Process to run the registry scripts? Does it offer any specific advantages over the previous method?

Why not keep these consistent with other manifests? Inconsistency across manifests can be quite confusing for new contributors. Also, I don't see the necessity of refactoring scripts that are already straightforward and easy to verify. Changing them to a more complex structure doesn't seem to offer much benefit, but it does make the code harder to audit at a glance.

@SorYoshino

Copy link
Copy Markdown
Contributor Author
  1. Phrasing: I believe "For file associations, run:" is more concise and idiomatic.

I think it is not sufficiently formal.

2. Wildcards: Specifying the .reg scripts explicitly was clearer. What's the rationale for switching to wildcards?

If there are many .reg files, specifying them directly may result in excessively long lines of code. Even when only a few .reg files are present, using a wildcard remains a more general approach, as it avoids modifying the code to accommodate different file names.

3. Process Execution: Why use Start-Process to run the registry scripts? Does it offer any specific advantages over the previous method?

It does not provide any real advantage. Scoop is implemented in PowerShell, and although reg import can be executed in PowerShell without issues, its syntax is primarily oriented toward cmd.


Why not keep these consistent with other manifests? Inconsistency across manifests can be quite confusing for new contributors. Also, I don't see the necessity of refactoring scripts that are already straightforward and easy to verify. Changing them to a more complex structure doesn't seem to offer much benefit, but it does make the code harder to audit at a glance.

I personally place greater emphasis on general applicability. This allows contributors to reuse these scripts without needing to consider various specific scenarios, such as modifying parts of the script due to different file names or updating the script whenever a .reg file is added or removed.

@z-Fng

z-Fng commented Apr 5, 2026

Copy link
Copy Markdown
Member

I personally place greater emphasis on general applicability.

These scripts aren't generalized enough for universal use yet.

$content -replace '{{librecad_dir}}', $librecad_dir

Besides, using wildcards in the installation directory could introduce many unforeseen issues.

Get-ChildItem -Path $dir -Filter 'un*.reg' -File

IMO improving general applicability isn't as important as maintaining clarity and intuitiveness. I believe making it easy to understand at a glance benefits both contributors and reviewers.

But since it works, let's merge it for now... We still have a bunch of issues to discuss anyway. ScoopInstaller/Main#7061

@z-Fng z-Fng left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution!

@z-Fng z-Fng merged commit 1fb8b37 into ScoopInstaller:master Apr 5, 2026
4 checks passed
@SorYoshino SorYoshino deleted the librecad branch April 6, 2026 04:32
@SorYoshino

Copy link
Copy Markdown
Contributor Author

These scripts aren't generalized enough for universal use yet.

$content -replace '{{librecad_dir}}', $librecad_dir

Sorry, I do not fully understand why you consider $content -replace '{{librecad_dir}}', $librecad_dir to be insufficiently general. In my view, $app_dir simply represents the directory where the application is stored, and it should be adjusted accordingly depending on the situation.

In my design, when the application contents are located in $dir but the binary is placed in $dir\bin or another subdirectory, the value of $app_dir would remain $dir -replace '\\', '\\'. In this case, the binary path in the .reg file would be {{app_dir}}\\bin\\binary.exe.

When the application contents are located in $dir\subfolder, the value of $app_dir would be "$dir\subfolder" -replace '\\', '\\'. In this case, the binary path in the .reg file would be {{app_dir}}\\binary.exe.

Besides, using wildcards in the installation directory could introduce many unforeseen issues.

Get-ChildItem -Path $dir -Filter 'un*.reg' -File

Admittedly, such a situation could occur, but I believe this approach still covers the vast majority of cases. Generality does not mean covering every possible scenario; being applicable to most cases is sufficient.

The current script only retrieves files under $dir whose names match un*.reg, and does not search deeper directories. In most situations, this causes no issues. If an exceptional case arises, the logic can be adjusted slightly. Compared with modifying the script every time a .reg file is added or removed, using a wildcard is more convenient.

IMO improving general applicability isn't as important as maintaining clarity and intuitiveness. I believe making it easy to understand at a glance benefits both contributors and reviewers.

I think that clarity and intuitiveness are closely related to personal habits. While using wildcards may be less explicit than specifying file names in certain situations, this does not necessarily mean that wildcards are inherently unclear or unintuitive.

For contributors, many may only contribute occasionally and may not be familiar with PowerShell syntax. Using more general approaches allows them to apply these scripts in most cases without needing to adjust them for specific circumstances. In my view, this lowers the barrier to contribution to some extent, as contributors do not need to fully understand the script or modify it based on file names; they can simply copy and use it.

For reviewers, such a general approach effectively provides a standardized template. It may cause some confusion during the initial review, but once the pattern is recognized, manifests that follow the same template no longer require extensive verification. In addition, when this approach is used, adding or removing multiple .reg files in the future will not require modifying the corresponding script logic, which helps keep subsequent changes more focused. In the long run, I believe establishing certain conventions and using this approach will be more convenient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants