Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://ryan.freumh.org/2025-03-10.html",
3 "title": "10 Mar 2025",
4 "link": "https://ryan.freumh.org/2025-03-10.html",
5 "updated": "2025-03-10T00:00:00",
6 "published": "2025-03-10T00:00:00",
7 "summary": "<div>\n <span> Previous: <a href=\"2025-03-03.html\"> 3 Mar 2025</a> </span>\n <span> Next: <a href=\"2025-03-17.html\">17 Mar 2025</a> </span>\n </div>\n \n \n\n <ol>\n<li><p><span>Babel</span></p>\n<ol>\n<li><p><span><span>~</span> python\npubgrub</span></p>\n<p><span>Using Uv’s <a href=\"https://github.com/astral-sh/uv/blob/c48af312aee48a000a23722ecfdddbe5a4037f78/crates/uv-resolver/src/dependency_provider.rs#L13\">dependency\nprovider</a>.</span></p>\n<p><span>This isn’t feasible at present, as Uv implements a\ncustom resolver.</span></p></li>\n<li><p><span><span>X</span> cargo\npubgrub</span></p>\n<p><span>Got a <a href=\"https://github.com/RyanGibb/babel/commit/dcdb92a6840b3d78e3737bb448bf0937d1c9964c\">cargo\ndependency provider</a> working modified from a repository used to\nbenchmark <code>pubgrub-rs</code> on solving the cargo\nrepository.</span></p>\n<pre><code>(Root, ) -> (Cargo Bucket:serde@1.x.y, SemverPubgrub { norml: 1.0.219, pre: ∅ } )\n(Cargo Bucket:serde@1.x.y, 1.0.219) -> (Cargo Bucket:serde_derive@1.x.y, SemverPubgrub { norml: >=1.0.219, <1.0.220, pre: ∅ } ), (Cargo Bucket:serde_derive@1.x.y/default=true, SemverPubgrub { norml: >=1.0.219, <1.0.220, pre: ∅ } )\n(Cargo Bucket:serde_derive@1.x.y, 1.0.219) -> (Cargo Bucket:quote@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/parsing, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/derive, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/clone-impls, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:quote@1.x.y, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: >=1.0.74, <2.0.0, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.74, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/proc-macro, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/printing, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } )\n(Cargo Bucket:serde_derive@1.x.y/default=true, 1.0.219) -> (Cargo Bucket:serde_derive@1.x.y, SemverPubgrub { norml: 1.0.219, pre: ∅ } ), (Cargo Bucket:serde_derive@1.x.y/default, SemverPubgrub { norml: 1.0.219, pre: ∅ } )\n(Cargo Bucket:quote@1.x.y/proc-macro, 1.0.40) -> (Cargo Bucket:quote@1.x.y, SemverPubgrub { norml: 1.0.40, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.80, <2.0.0, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/parsing, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y, 2.0.100) -> (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: >=1.0.91, <2.0.0, pre: ∅ } ), (Cargo Bucket:unicode-ident@1.x.y, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } ), (Cargo Bucket:unicode-ident@1.x.y/default=true, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/derive, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/clone-impls, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:quote@1.x.y, 1.0.40) -> (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: >=1.0.80, <2.0.0, pre: ∅ } )\n(Cargo Bucket:proc-macro2@1.x.y, 1.0.94) -> (Cargo Bucket:unicode-ident@1.x.y, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } ), (Cargo Bucket:unicode-ident@1.x.y/default=true, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } )\n(Cargo Bucket:proc-macro2@1.x.y/proc-macro, 1.0.94) -> (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: 1.0.94, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/proc-macro, 2.0.100) -> (Cargo Bucket:quote@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/dep:quote, SemverPubgrub { norml: 2.0.100, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.91, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/printing, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/dep:quote, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:serde_derive@1.x.y/default, 1.0.219) -> (Cargo Bucket:serde_derive@1.x.y, SemverPubgrub { norml: 1.0.219, pre: ∅ } )\n(Cargo Bucket:unicode-ident@1.x.y, 1.0.18)\n(Cargo Bucket:unicode-ident@1.x.y/default=true, 1.0.18) -> (Cargo Bucket:unicode-ident@1.x.y, SemverPubgrub { norml: 1.0.18, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/dep:quote, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } ), (Cargo Bucket:quote@1.x.y, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } )\n</code></pre>\n<p><span>You’ll notice the concept of version ranges in this\ndependency provider has a ‘normal’ range, and a ‘pre’ range, so I had to\nadd an abstract <code>BabelVersionSet</code> to\ninteroperate with the other dependency providers.</span></p>\n<p><span>At the moment this loads the whole index at once\nwhich takes a long time, so I need to figure out how to make <code>pubgrub_cargo</code> dynamically load\npackages.</span></p>\n<p><span>Getting Claude code to attempt this failed quite\nspectacularly, so I guess my job’s safe (for now);</span></p>\n<blockquote>\n<p><span>We’ve run into significant challenges with\nimplementing on-demand loading for the Cargo Index. The core issue is\nthat the API was designed around a pre-loaded data model where all\nreferences have the same lifetime as the Index object.</span></p>\n<p><span>Our efforts to update the code to use on-demand\nloading led us to the following conclusions:</span></p>\n<p><span>Lifetime issues: Dependencies loaded on-demand\ndon’t live long enough to satisfy the lifetime requirements of the API,\nwhich expects references that live for the entire lifetime of the Index.\nOwnership complexity: Even when cloning data to avoid borrowing issues,\nwe still run into problems with the DependencyProvider trait expecting\nreferences with specific lifetimes. Deep architectural dependencies: The\ndesign assumes references are valid throughout the library’s operation,\nmaking it difficult to use dynamically loaded data without changing core\nAPIs.</span></p>\n<p><span>Recommendation:</span></p>\n<p><span>For now, we should document these findings and\nrevert to the pre-loaded approach while planning a more comprehensive\nredesign of the API to better support on-demand loading. This would\ninvolve:</span></p>\n<p><span>Redesigning the DependencyProvider trait to work\nwith owned data rather than references Updating the Names and Package\ntypes to avoid lifetime parameters Creating a proper caching layer for\ndynamically loaded data</span></p>\n<p><span>This is a valuable learning experience that\nhighlights the challenges of retrofitting on-demand loading into a\nsystem designed around pre-loaded data with static lifetim</span></p>\n</blockquote>\n<blockquote>\n<p><span>Redesigning pubgrub_cargo to use an owned data\napproach like pubgrub_opam would be a substantial undertaking. Here’s a\nbreakdown of the work involved: Scope of Changes</span></p>\n<p><span>Core Type Redesign (3-5 days) Remove lifetime\nparameters from Names, Dependency, Index, and other key structs Redesign\nthese to be fully owned types that implement Clone Update method\nsignatures throughout the codebase</span></p>\n<p><span>DependencyProvider Implementation (2-3 days)\nRewrite methods like get_versions, get_version, and get_dependencies to\nreturn owned data Handle on-demand loading with proper\ncaching</span></p>\n<p><span>Package Resolution Logic (3-5 days) Modify pubgrub\nintegration to work with owned data Update logic in from_dep,\ncheck_cycles, etc. to work without lifetime references</span></p>\n<p><span>Testing & Debugging (3-5 days) Fix all the\ntest cases that would break Debug subtle issues with different data\nownership patterns Ensure performance remains acceptable</span></p>\n<p><span>Challenges</span></p>\n<p><span>Deep Architectural Change: The lifetime parameters\nare embedded deeply in the API, affecting almost every function.\nInterface Consistency: Need to ensure the redesign doesn’t break clients\nof the library. Performance Tradeoffs: Switching to owned data means\nmore cloning, which could impact performance.</span></p>\n<p><span>Total Estimate</span></p>\n<p><span>A skilled Rust developer with good knowledge of\nthe codebase would likely need 2-3 weeks of focused work to complete\nthis redesign properly. The work would include refactoring, testing,\ndebugging, and performance optimization.</span></p>\n<p><span>If you just need a minimal working solution for\nnow, reverting to the preloaded approach with selective loading of\ncommon packages might be a better near-term solution while planning the\nlarger redesign.</span></p>\n</blockquote>\n<p><span>The AI (and myself) both have a lot of issues with\nRust lifetimes, and I really don’t care about optimising anything at\nthis point. I miss OCaml’s garbage collector and am tempted to implemnt\nthe Pubgrub algorithm in Oxidised OCaml.</span></p></li>\n<li><p><span><span>O</span> forking\nresolving for portable lockfiles</span></p>\n<p><span>See Uv’s resolver.</span></p></li>\n<li><p><span>Evaluation</span></p>\n<ul>\n<li>stunt 1: cross-ecosystem solving\n<ul>\n<li>system dependency solving\n<ul>\n<li>debian and alpine</li>\n</ul></li>\n<li>ocaml polars</li>\n</ul></li>\n<li>stunt 2: portable lock files\n<ul>\n<li>portability metric</li>\n<li>semantics from formalism</li>\n<li>look at what uv does</li>\n<li>add to table 1</li>\n</ul></li>\n<li>stunt 3: cross-compilation\n<ul>\n<li>solving architectures</li>\n</ul></li>\n</ul></li>\n<li><p><span>Providing packages</span></p>\n<ul>\n<li>docker?</li>\n<li>Nix?</li>\n<li>namespaces?</li>\n</ul></li>\n</ol></li>\n</ol>",
8 "content": "<div>\n <span> Previous: <a href=\"2025-03-03.html\"> 3 Mar 2025</a> </span>\n <span> Next: <a href=\"2025-03-17.html\">17 Mar 2025</a> </span>\n </div>\n \n \n\n <ol>\n<li><p><span>Babel</span></p>\n<ol>\n<li><p><span><span>~</span> python\npubgrub</span></p>\n<p><span>Using Uv’s <a href=\"https://github.com/astral-sh/uv/blob/c48af312aee48a000a23722ecfdddbe5a4037f78/crates/uv-resolver/src/dependency_provider.rs#L13\">dependency\nprovider</a>.</span></p>\n<p><span>This isn’t feasible at present, as Uv implements a\ncustom resolver.</span></p></li>\n<li><p><span><span>X</span> cargo\npubgrub</span></p>\n<p><span>Got a <a href=\"https://github.com/RyanGibb/babel/commit/dcdb92a6840b3d78e3737bb448bf0937d1c9964c\">cargo\ndependency provider</a> working modified from a repository used to\nbenchmark <code>pubgrub-rs</code> on solving the cargo\nrepository.</span></p>\n<pre><code>(Root, ) -> (Cargo Bucket:serde@1.x.y, SemverPubgrub { norml: 1.0.219, pre: ∅ } )\n(Cargo Bucket:serde@1.x.y, 1.0.219) -> (Cargo Bucket:serde_derive@1.x.y, SemverPubgrub { norml: >=1.0.219, <1.0.220, pre: ∅ } ), (Cargo Bucket:serde_derive@1.x.y/default=true, SemverPubgrub { norml: >=1.0.219, <1.0.220, pre: ∅ } )\n(Cargo Bucket:serde_derive@1.x.y, 1.0.219) -> (Cargo Bucket:quote@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/parsing, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/derive, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/clone-impls, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:quote@1.x.y, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: >=1.0.74, <2.0.0, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.74, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/proc-macro, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/printing, SemverPubgrub { norml: >=2.0.81, <3.0.0, pre: ∅ } )\n(Cargo Bucket:serde_derive@1.x.y/default=true, 1.0.219) -> (Cargo Bucket:serde_derive@1.x.y, SemverPubgrub { norml: 1.0.219, pre: ∅ } ), (Cargo Bucket:serde_derive@1.x.y/default, SemverPubgrub { norml: 1.0.219, pre: ∅ } )\n(Cargo Bucket:quote@1.x.y/proc-macro, 1.0.40) -> (Cargo Bucket:quote@1.x.y, SemverPubgrub { norml: 1.0.40, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.80, <2.0.0, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/parsing, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y, 2.0.100) -> (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: >=1.0.91, <2.0.0, pre: ∅ } ), (Cargo Bucket:unicode-ident@1.x.y, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } ), (Cargo Bucket:unicode-ident@1.x.y/default=true, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/derive, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/clone-impls, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:quote@1.x.y, 1.0.40) -> (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: >=1.0.80, <2.0.0, pre: ∅ } )\n(Cargo Bucket:proc-macro2@1.x.y, 1.0.94) -> (Cargo Bucket:unicode-ident@1.x.y, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } ), (Cargo Bucket:unicode-ident@1.x.y/default=true, SemverPubgrub { norml: >=1.0.0, <2.0.0, pre: ∅ } )\n(Cargo Bucket:proc-macro2@1.x.y/proc-macro, 1.0.94) -> (Cargo Bucket:proc-macro2@1.x.y, SemverPubgrub { norml: 1.0.94, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/proc-macro, 2.0.100) -> (Cargo Bucket:quote@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/dep:quote, SemverPubgrub { norml: 2.0.100, pre: ∅ } ), (Cargo Bucket:proc-macro2@1.x.y/proc-macro, SemverPubgrub { norml: >=1.0.91, <2.0.0, pre: ∅ } ), (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/printing, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } ), (Cargo Bucket:syn@2.x.y/dep:quote, SemverPubgrub { norml: 2.0.100, pre: ∅ } )\n(Cargo Bucket:serde_derive@1.x.y/default, 1.0.219) -> (Cargo Bucket:serde_derive@1.x.y, SemverPubgrub { norml: 1.0.219, pre: ∅ } )\n(Cargo Bucket:unicode-ident@1.x.y, 1.0.18)\n(Cargo Bucket:unicode-ident@1.x.y/default=true, 1.0.18) -> (Cargo Bucket:unicode-ident@1.x.y, SemverPubgrub { norml: 1.0.18, pre: ∅ } )\n(Cargo Bucket:syn@2.x.y/dep:quote, 2.0.100) -> (Cargo Bucket:syn@2.x.y, SemverPubgrub { norml: 2.0.100, pre: ∅ } ), (Cargo Bucket:quote@1.x.y, SemverPubgrub { norml: >=1.0.35, <2.0.0, pre: ∅ } )\n</code></pre>\n<p><span>You’ll notice the concept of version ranges in this\ndependency provider has a ‘normal’ range, and a ‘pre’ range, so I had to\nadd an abstract <code>BabelVersionSet</code> to\ninteroperate with the other dependency providers.</span></p>\n<p><span>At the moment this loads the whole index at once\nwhich takes a long time, so I need to figure out how to make <code>pubgrub_cargo</code> dynamically load\npackages.</span></p>\n<p><span>Getting Claude code to attempt this failed quite\nspectacularly, so I guess my job’s safe (for now);</span></p>\n<blockquote>\n<p><span>We’ve run into significant challenges with\nimplementing on-demand loading for the Cargo Index. The core issue is\nthat the API was designed around a pre-loaded data model where all\nreferences have the same lifetime as the Index object.</span></p>\n<p><span>Our efforts to update the code to use on-demand\nloading led us to the following conclusions:</span></p>\n<p><span>Lifetime issues: Dependencies loaded on-demand\ndon’t live long enough to satisfy the lifetime requirements of the API,\nwhich expects references that live for the entire lifetime of the Index.\nOwnership complexity: Even when cloning data to avoid borrowing issues,\nwe still run into problems with the DependencyProvider trait expecting\nreferences with specific lifetimes. Deep architectural dependencies: The\ndesign assumes references are valid throughout the library’s operation,\nmaking it difficult to use dynamically loaded data without changing core\nAPIs.</span></p>\n<p><span>Recommendation:</span></p>\n<p><span>For now, we should document these findings and\nrevert to the pre-loaded approach while planning a more comprehensive\nredesign of the API to better support on-demand loading. This would\ninvolve:</span></p>\n<p><span>Redesigning the DependencyProvider trait to work\nwith owned data rather than references Updating the Names and Package\ntypes to avoid lifetime parameters Creating a proper caching layer for\ndynamically loaded data</span></p>\n<p><span>This is a valuable learning experience that\nhighlights the challenges of retrofitting on-demand loading into a\nsystem designed around pre-loaded data with static lifetim</span></p>\n</blockquote>\n<blockquote>\n<p><span>Redesigning pubgrub_cargo to use an owned data\napproach like pubgrub_opam would be a substantial undertaking. Here’s a\nbreakdown of the work involved: Scope of Changes</span></p>\n<p><span>Core Type Redesign (3-5 days) Remove lifetime\nparameters from Names, Dependency, Index, and other key structs Redesign\nthese to be fully owned types that implement Clone Update method\nsignatures throughout the codebase</span></p>\n<p><span>DependencyProvider Implementation (2-3 days)\nRewrite methods like get_versions, get_version, and get_dependencies to\nreturn owned data Handle on-demand loading with proper\ncaching</span></p>\n<p><span>Package Resolution Logic (3-5 days) Modify pubgrub\nintegration to work with owned data Update logic in from_dep,\ncheck_cycles, etc. to work without lifetime references</span></p>\n<p><span>Testing & Debugging (3-5 days) Fix all the\ntest cases that would break Debug subtle issues with different data\nownership patterns Ensure performance remains acceptable</span></p>\n<p><span>Challenges</span></p>\n<p><span>Deep Architectural Change: The lifetime parameters\nare embedded deeply in the API, affecting almost every function.\nInterface Consistency: Need to ensure the redesign doesn’t break clients\nof the library. Performance Tradeoffs: Switching to owned data means\nmore cloning, which could impact performance.</span></p>\n<p><span>Total Estimate</span></p>\n<p><span>A skilled Rust developer with good knowledge of\nthe codebase would likely need 2-3 weeks of focused work to complete\nthis redesign properly. The work would include refactoring, testing,\ndebugging, and performance optimization.</span></p>\n<p><span>If you just need a minimal working solution for\nnow, reverting to the preloaded approach with selective loading of\ncommon packages might be a better near-term solution while planning the\nlarger redesign.</span></p>\n</blockquote>\n<p><span>The AI (and myself) both have a lot of issues with\nRust lifetimes, and I really don’t care about optimising anything at\nthis point. I miss OCaml’s garbage collector and am tempted to implemnt\nthe Pubgrub algorithm in Oxidised OCaml.</span></p></li>\n<li><p><span><span>O</span> forking\nresolving for portable lockfiles</span></p>\n<p><span>See Uv’s resolver.</span></p></li>\n<li><p><span>Evaluation</span></p>\n<ul>\n<li>stunt 1: cross-ecosystem solving\n<ul>\n<li>system dependency solving\n<ul>\n<li>debian and alpine</li>\n</ul></li>\n<li>ocaml polars</li>\n</ul></li>\n<li>stunt 2: portable lock files\n<ul>\n<li>portability metric</li>\n<li>semantics from formalism</li>\n<li>look at what uv does</li>\n<li>add to table 1</li>\n</ul></li>\n<li>stunt 3: cross-compilation\n<ul>\n<li>solving architectures</li>\n</ul></li>\n</ul></li>\n<li><p><span>Providing packages</span></p>\n<ul>\n<li>docker?</li>\n<li>Nix?</li>\n<li>namespaces?</li>\n</ul></li>\n</ol></li>\n</ol>",
9 "content_type": "html",
10 "categories": [],
11 "source": "https://ryan.freumh.org/atom.xml"
12}