11# ` pantry^2 `
22
3- - Configuration is hardcoded to /etc
4- - We use vendor-built binaries where possible
5- - We assume the vendor knows how to build their product better than us
6- - Means issues are almost always upstream and not ours
7- - Notably excepting when the prebuilt binaries vendor libraries we provide
8- - windows/x86-64 support from day 1
9- - Relocatable without environment fixes for all base packages
10- - If we package a package manager and it provides a tool (in a unpainful way)
11- then pkgx will invoke that other tool to get the thing
12- - eg. ` cargo-binstall ` , ` npx ` , ` uvx ` etc. will be used instead of us
13- packaging them
14- - these other mechanisms are generally _ preferred_ by the developer and
15- end-user, we'll just know how to get you the end-product with a consistent
16- CLI
17- - this means we can focus on ensuring the base is as good as possible
18- without distraction from a massive pkg list
19- - We will still index everything and show it at [ pkgx.dev/pkgs]
20- - Minimizing deps on macOS
21- - we added deps because Linux needed them in v1 due to laziness and urgency
3+ ## Goals
4+
5+ - Better optimized packages
6+ - Much more careful dependency selection
7+ - We have reviewed everything that is transitive thoroughly
8+ - Leaner, more streamlined packages
9+ - Python reduced from 280MB to 78MB
10+ - LLVM pruned to just what is needed and split out into multiple packages
11+ reduing its size from 1.5GB to 300MB
12+ - More consistent namespacing
13+ - More reliable builds
14+ - More robust bottles
15+ - eg. ` rpath ` fixes are now much more thorough and careful
16+ - Better configured and more consistently configured packages
17+ - In general we set configuration to be ` /etc ` with user config carve outs
18+ - Across the board dependency on OpenSSL^3 rather ^1.1.1
19+ - Use of macOS system libraries where possible
20+ - Windows native support
21+ - Faster build infrastructure
22+ - More minimal pre-requisite footprint on Linux
23+ - 100% relocatable packages without environment fixes for all base packages
24+ - Use vendor built binaries where possible and sensible
25+ - Provided the vendor does not statically link in libraries this is a
26+ better choice since we assume the vendor knows how to build their product
27+ better than us
2228- No magic
23- - git no longer looks for ` git-foo ` if you type ` git foo `
24- - etc.
25- - we would consider adding these back, but not as _ part_ of the package
26- itself. The package itself should solely focus on our other goals and
27- otherwise be vanilla.
28- - ` pkgx^1,^2 ` will use pantry^1, ` pkgx^3 ` will use pantry^2
29- - building with as minimal images as is possible to ensure we are sure about
30- what goes into our packages
29+ - eg. ` git ` stub that looks to ` pkgx ` for ` git-foo `
30+ - More flexible build infrastructure
31+ - Less unwise hacks
32+ - eg. symlinking versioned include directories, instead we now set ` CPATH `
33+ in the package.yaml runtime env
34+ - Separating out eg. ` gem ` from Ruby for purity reasons was a mistake
35+ - No more packaging for projects without versioning or with careless
36+ versioning. Eg. ` llama.cpp ` and ` vim ` .
37+ - Users still want these so we can instead make them build from source on
38+ demand.
39+ - It is gross currently since these projects release multiple times * a day*
40+
41+ ## Future Goals
42+
3143- First class ` pkgm ` support
3244 - everything should install to ` /usr/local ` and just work
33- - No weird handling for calver
34- - no (or much less) pre-reqs on Linux
35- - we only need glibc and libgcc
36- - strictly we don’t need the user to provide libgcc, but us building and
37- using our own is more or a pita than we can handle RN
38- - variable deps
39- - eg. a major version requires new deps
40- - eg. heaven forbid, a minor version changes the dep constraint
41- - sources tarball locations can vary by version
42- - program lists can vary by version
43- - no deversioning of inner directories (for ` pkgm ` )
44- - no support for dollar prefixed moustaches in ` package.yml `
45- - independently versioned things must be independent
46- - generally we are already good at this
47- - things without established versioning and/or programs are not valid to be
48- packaged. They go in ` pkgo `
45+ - Zero pre-requisties on Linux
46+ - Dependencies can vary by version
47+ - Program lists can vary by version
4948- standardize pkgs
5049 - use XDG and standard dirs on other platforms
5150 - configure things that install things to install them to
5251 ` ${INSTALL_ROOT:-$HOME/.local} ` by default
53- - more consistent project names
54- - no foo.github.io, just github.com/foo etc.
55- - no strict adherance to homepages, it's more about namespacing
56-
57- [ pkgx.dev/pkgs ] : https://pkgx.dev/pkgs
5852
5953## Usage
6054
@@ -94,18 +88,6 @@ $ ls bin
9488
9589- glibc, libgcc and their ` -dev ` pkgs are still required at this time
9690
97- ## Wins
98-
99- - Python from 280MB to 78MB
100- - Cleaner rpath handling across the board
101- - linux rpath fixes were actually broken with ` pantry^1 `
102- - Less env pollution by carefully using ` pkgx ` during builds rather than
103- importing dep-envs before builds, meaning more reliable builds with less
104- unexpected deps
105- - Carefuly pruning of deps and build options for all base deps
106- - much tighter python venv handling
107- - more XDG adherance for base packages
108-
10991### Build Infra Wins
11092
11193- a pkg depending on itself now works without conflict since destination
@@ -129,34 +111,6 @@ complexity mounts and mounts. You may as well just use a real language.
129111
130112Also we needed a cross platform language to support Windows. Bash is not that.
131113
132- ### Criteria for Inclusion
133-
134- - We require that packages are versioned.
135- - We require that the project bew licensed such that we are permitted to
136- redistribute it.
137- - Stuff that is so new that its build instructions are likely to change a lot
138- in future may be rejected due to our inability to reliably maintain that.
139- - Things that can have other general executors (eg. npx) should be run that
140- way using the ` providers ` system.
141- - Things that do not respect reasonable release schedules may be rejected
142- (eg. we have seen packages release 10+ times a day, every day).
143-
144- ### Requirements
145-
146- For local builds we need some stuff set up:
147-
148- * macOS
149- * The Xcode Command Line Tools are expected to be installed
150- * Windows
151- * Visual Studio Community Edition with C++
152- * Some things expect ` nmake ` and thus you will need to run a
153- “developer prompt”
154- * Linux
155- * glibc libs and headers
156- * stdc++
157-
158- Mostly, otherwise we source build tools from ` pkgx ` .
159-
160114### Boostrapping New Platforms
161115
162116You will need preinstalled versions of the following:
0 commit comments