| 17 Jul 2025 |
 emily | usually stuff like that is left to out of tree repos | 21:22:08 |
 msgilligan | But step 1 and 2 of the list of the above could me merged separately, I assume. | 21:26:46 |
| msgilligan | And, as far as making it available "out of tree", what would be the best way to do that? | 21:27:12 |
| emily | for sure for #1, it should probably get the token from the environment like other tooling
for #2 I guess it depends on the complexity of the code change and whether we worry about EA versions being added accidentally - if we don't expect that we'd want to exercise the functionality in Nixpkgs
| 21:28:11 |
| emily | In reply to @msgilligan:matrix.org
And, as far as making it available "out of tree", what would be the best way to do that? the standard thing these days would be to make a flake. we could expose generic builders for the relevant packages that can be supplied arbitrary versions from Nixpkgs if it would make that task easier l | 21:28:58 |
| msgilligan | Would (or could) that flake be an "overlay"? It would be nice if I could add 25-EA and then have packages like Gradle and JBang be configured to use that JDK. That (or a similar mechanism) would also allow the build of 25 to get some testing. | 21:30:55 |
| emily | it can be, but you don't need an overlay to use out of tree packages either | 21:33:41 |
| msgilligan | I know that raboof created an "out of tree" solution here, but I don't know how to use it from a flake and it seems more like a very separate thing, not something this is a "preview" of something that will move to Nixpkgs. | 21:34:35 |
| msgilligan | I think the ideal way would be able to access the PRs branch directly and I've seen flakes that use both a stable and unstable release of Nixpkgs, so I think that approach should work. That would also make it easier to rebase and to adapt for new EA releases after the current EA becomes GA. | 21:37:41 |
| emily | yeah, that very much works | 21:43:06 |
| emily | you don't necessarily need two Nixpkgses since GitHub has magic refs that represent the state if the PR was merged | 21:43:45 |
 Infinidoge 🏳️⚧️ | The unfortunate thing with PR branches vs overlays or grabbing directly is that PR branches usually aren't kept up to date, and usually don't follow with a standard stable branch | 21:43:47 |
| Infinidoge 🏳️⚧️ | Oh good magic ref, that works | 21:43:58 |
| emily | though in the presence of merge conflicts that doesn't work so great :) | 21:44:00 |
| Infinidoge 🏳️⚧️ | If flakes supported patches for inputs the world would be at peace | 21:44:20 |
| Infinidoge 🏳️⚧️ | But alas | 21:44:25 |
| Infinidoge 🏳️⚧️ | IFD | 21:44:26 |
| Infinidoge 🏳️⚧️ | I have hope for Fetch Tree, but only hope | 21:44:35 |
| emily | I don't think fetchTree changes anything there | 21:45:44 |
| Infinidoge 🏳️⚧️ | I think the ideal solution would be an out-of-tree repo exposing packages through flakes and an overlay, with a structure identical to how the packages would be in Nixpkgs, so they can be directly transferred in later | 21:45:47 |
| emily | honestly using the PR refs seems fine to me. I just, like, wouldn't deploy it in pros | 21:46:34 |
| emily | * | 21:46:39 |
| emily | but I wouldn't deploy an EA version in prod to begin with :) | 21:46:51 |
| msgilligan | I need to learn about magic refs then. | 21:49:22 |
| msgilligan | Since I'm (mostly) on Darwin, I use Home Manager, so I would add the JDK-ea Nixpkgs as an additional input. | 21:50:57 |
| msgilligan | * Since I'm (mostly) on Darwin, I use Home Manager, so I would add the JDK-ea Nixpkgs as an additional input (to my flake-based Home Manager config) | 21:51:14 |
| Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org
I don't think fetchTree changes anything there Eelco suggested adding a patches option to fetchTree, which would support directly applying patches to an input without IFD
it isn't something that currently exists In Reality though, which is why it's only hope and not anticipation
| 21:51:18 |
| Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org
I don't think fetchTree changes anything there * Eelco (supposedly, this isn't directly from him) suggested adding a patches option to fetchTree, which would support directly applying patches to an input without IFD
it isn't something that currently exists In Reality though, which is why it's only hope and not anticipation
| 21:51:30 |
| emily | right | 21:52:21 |
| emily | tbh just maintaining a fork is the most convenient thing, give appropriate tooling | 21:52:48 |
