Resolve external dependency conflict with zero-dep philosophy #7

Open
opened 2026-03-17 12:26:23 +01:00 by michael · 2 comments
Owner

Summary

README states "zero external dependencies required" but two modules
have hard external requirements:

  • fs.lua requires luafilesystem (lfs)
  • http_client.lua requires luasocket (socket.http + ltn12)

This contradicts the project philosophy.

Options

A) Accept external deps -- update philosophy statement

Mark fs.lua and http_client.lua as "requires external dep" clearly
in README. Philosophy becomes "core modules zero-dep, utility modules
documented deps". Simple, honest.

B) Pure Lua fallbacks per module

Each module tries the external lib first, falls back to pure Lua
implementation (same 2-tier pattern as json.lua and yaml.lua).

  • fs.lua: lfs tier 1, io/os-based tier 2 (limited but functional)
  • http_client.lua: luasocket tier 1, no pure-Lua HTTP feasible

Problem: pure Lua HTTP is not realistic. Option B only works for fs.lua.

C) Split into daw-lua-common and daw-lua-common-ext

  • daw-lua-common: zero external deps (uuid, json, yaml, time, config_parser)
  • daw-lua-common-ext: modules with external deps (fs, http_client)

Clean separation, callers know what they depend on.

Decision needed

Which option? Recommendation: A for http_client (no realistic fallback),
B for fs (lfs fallback to io/os is feasible), or C for clean split.

Affected modules

  • src/daw/lua/common/fs.lua
  • src/daw/lua/common/http_client.lua

Refs

DAW/daw-lua-common#5

## Summary README states "zero external dependencies required" but two modules have hard external requirements: - fs.lua requires luafilesystem (lfs) - http_client.lua requires luasocket (socket.http + ltn12) This contradicts the project philosophy. ## Options ### A) Accept external deps -- update philosophy statement Mark fs.lua and http_client.lua as "requires external dep" clearly in README. Philosophy becomes "core modules zero-dep, utility modules documented deps". Simple, honest. ### B) Pure Lua fallbacks per module Each module tries the external lib first, falls back to pure Lua implementation (same 2-tier pattern as json.lua and yaml.lua). - fs.lua: lfs tier 1, io/os-based tier 2 (limited but functional) - http_client.lua: luasocket tier 1, no pure-Lua HTTP feasible Problem: pure Lua HTTP is not realistic. Option B only works for fs.lua. ### C) Split into daw-lua-common and daw-lua-common-ext - daw-lua-common: zero external deps (uuid, json, yaml, time, config_parser) - daw-lua-common-ext: modules with external deps (fs, http_client) Clean separation, callers know what they depend on. ## Decision needed Which option? Recommendation: A for http_client (no realistic fallback), B for fs (lfs fallback to io/os is feasible), or C for clean split. ## Affected modules - src/daw/lua/common/fs.lua - src/daw/lua/common/http_client.lua ## Refs DAW/daw-lua-common#5
Author
Owner

Decision 2026-03-17

Option C: Split into separate repository.

  • daw-lua-common: zero external deps (uuid, json, yaml, time, config_parser)
  • daw-lua-common-ext: modules with external deps (fs, http_client)

Submodule mechanism identical to daw-lua-common.
Projects include both as needed:
src/lib -> daw-lua-common
src/lib-ext -> daw-lua-common-ext

Next step: create DAW/daw-lua-common-ext repo, move fs.lua and http_client.lua.

## Decision 2026-03-17 Option C: Split into separate repository. - daw-lua-common: zero external deps (uuid, json, yaml, time, config_parser) - daw-lua-common-ext: modules with external deps (fs, http_client) Submodule mechanism identical to daw-lua-common. Projects include both as needed: src/lib -> daw-lua-common src/lib-ext -> daw-lua-common-ext Next step: create DAW/daw-lua-common-ext repo, move fs.lua and http_client.lua.
Author
Owner

Decision 2026-07-19 (supersedes the 2026-03-17 decision to split into daw-lua-common-ext): Option B instead of Option C. fs/ stays in this repo and gets a shell-based fallback tier (lfs missing -> shell out via daw.common.sys, same 2-tier pattern as json/yaml), rather than moving to a separate repo. Rationale: fs is used pervasively across nearly every downstream module and host program; splitting it out would require a cross-repo migration with no corresponding benefit, since the license-compatibility concern that partly motivated the original split does not apply (lfs/cjson/dkjson/lyaml are all MIT, fully compatible with this repo's ISC license, and none of them are bundled/vendored here). daw-lua-common-ext remains unused for now. Scheduled for milestone 2.1, tracked together with #3.

Decision 2026-07-19 (supersedes the 2026-03-17 decision to split into daw-lua-common-ext): Option B instead of Option C. fs/ stays in this repo and gets a shell-based fallback tier (lfs missing -> shell out via daw.common.sys, same 2-tier pattern as json/yaml), rather than moving to a separate repo. Rationale: fs is used pervasively across nearly every downstream module and host program; splitting it out would require a cross-repo migration with no corresponding benefit, since the license-compatibility concern that partly motivated the original split does not apply (lfs/cjson/dkjson/lyaml are all MIT, fully compatible with this repo's ISC license, and none of them are bundled/vendored here). daw-lua-common-ext remains unused for now. Scheduled for milestone 2.1, tracked together with #3.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
DAW/daw-lua-common#7
No description provided.