2026-05-11 Mon

  • Cross-Repo Authentication and Python Package Management with GitHub/Apps

    • Use Case

      • In the context of a GitHub/Enterprise, we had two use cases.

      • Initial Use Case / Need

        • In a GitHub/Action in my-org/repo-a, call uv/sync on a python project that has a dependency on a python package from my-org/repo-b expressed as a git installation path

      • Long-Term Use Case / Need

        • In any GitHub Action in my-org, call uv/sync on a python project that has a dependency on a python package from any other GitHub/Repo marked as Internal

    • Challenge

    • Options

      • A - Use a GitHub App - CHOSEN

        • Create a github app with the Contents: read permission on my-org/repo-b
        • Use GitHub/Action/Create GitHub App Token action to obtain a short-lived credential
        • Use the short-lived credential to do the uv/sync after

      • B - Use a Service User

        • Create a github service user and grant it access to the GitHub/Org
        • Create a GitHub Fine-Grained Access Token with the Contents: read permission on my-org/repo-b
          • Install the PAT in GitHub/Org/Secret and use it in the github action to do the uv/sync

    • Implementing Option A - Use a GitHub/App

      • Created a GitHub/App titled <org>-ci-read-repo-contents-app
      • The app had repo contents: read permissions
      • Encountered some difficulty finding how a GitHub/Org/Admin could create a GitHub/App "inside" or owned by the GitHub Org. Ended up creating it in a personal account and transferring its ownership to the org.
      • After the app was owned by the GitHub/Enterprise GitHub/Org, GitHub/App/Settings were configured to enable reading all repositories.
      • Ensured that GitHub/App/Client ID and GitHub/App/Private Key as GitHub/Org/Secrets.
      • In my-org/my-repo-a, update pyproject.toml:
        • toml
          dependencies = [
    "my-org-repo-b"
]
[tool.uv.sources]
my-org-repo-b = { git = "https://github.com/my-org/repo-b.git" }
      • In my-org/my-repo-a, used the following GitHub/Action to pull the secrets out, generate a GitHub/App/Token. Everything here is scoped to my-org / MY_ORG
        • yml
              - name: Generate GitHub App token
      id: app-token
      uses: actions/create-github-app-token@v1
      with:
        app-id: ${{ secrets.MY_ORG_CI_READ_REPO_CONTENTS_APP_CLIENT_ID }}
        private-key: ${{ secrets.MY_ORG_CI_READ_REPO_CONTENTS_APP_PRIVATE_KEY }}
        owner: my-org

    - name: Configure git authentication for private repos
      run: |
        git config --global url."https://x-access-token:${{ steps.app-token.outputs.token }}@github.com/".insteadOf "https://github.com/"

    - name: Install uv
      uses: astral-sh/setup-uv@v8.1.0
      with:
        version: "latest"

    - name: Set up Python
      run: uv python install 3.12

    - name: Install dependencies
      run: uv sync
      • This ended up working.
      • In practice, in order to get to this point, first created .github/workflows/test-github-app-access.yml with just the steps necessary to prove cross-repo access.

2026-05-08 Fri

Linked references — 1 page

Open the linked references

2026-05-07 Thu

Linked references — 1 page

Open the linked references

2026-05-06 Wed

  • devcontainers

  • planning

    • moving away from NixOS and Nix/home-manager

      • typical arguments for moving away from nix

        • obscurity: it's not used in the enterprise outside of ReplitAI, some parts of Spotify, and customers of Determinate Systems

        • hard to understand and terrible documentation: many think that nix is extremely challenging. I'm not sure I agree.

          • in I found the documentation and resources available online to meet the minimum bar I need to use a system. This was not the primary barrier.
            • the fact that it has a reputation as being a hard system paradoxically also means
              • there are many people trying to help others to learn it, in order to understand it themselves, and in order to advertise their own abilities.
                • this is a great system for helping produce "adversity metabolized understanding," that is, the kind of community brainpower that is strengthened by difficulty
          • I actually appreciate learning systems and territories that also require acquiring new terminology. That's how my brain grows. Learning systems that have their own concepts conveys durable, hard-won advantages, even after those systems are no longer utilized.
            • Nix/Derivation
            • Nix/Overlay
            • Nix/Package
            • Nix/Module
            • Nix/flake
            • Nix/Store
      • personal arguments for moving away from Nix

        • too much overhead in practice at this time

          • the advantages of nix are awesome (the primary advantage is Declar/at/ive Reproduc/ibility).
          • but I paid for them too dearly relative to the benefit they conferred.
            • a comparison: from my perspective, greater than 50% of people who choose to exchange 5+ years to get a Ed/Degree/PhD today suffer from a type of Game/Theory/Winner/Curse
              • they seem to want some kind of proof they are smart, but aren't creative enough to think of any more useful ways to demonstrate and earn that recognition for their intelligence.
              • once upon a time, the benefit of getting a PhD relative to the effort was a much more beneficial ratio. From the 1930s to the 1970s there was a lot of low-hanging fruit out there. today, the benefit of a PhD relative to the work involved is not favorable from a cost-benefit point of view, with a few possible but rare exceptions.
                • in particular, the longer a field has competitive forces, the more the competition tends to become about "winning the race at the starting line" (aka luck-based) factors such as genetics and starting resources. so, to run a 1hr 51 minute Marathon just requires certain genes and resources. Similarly, becoming someone like Person/Alexander Wissner-Gross or Person/John von Neumann requires certain resources and genetics. I still think PhDs might be a good idea if you are in the top 3% in terms of your total luck allocation.
            • it's a similar thing with Nix - I would estimate that greater than 50% of people who choose to exchange 12+months in exchange for a nix setup got the raw end of the deal.
              • Some systems get faster the more people optimize for them. I get the sense that the more people actually rely on nix, the more overhead those people and companies actually accrue.
          • people talk about how the Nix/Package/Manager is the biggest in the world. in my experience, almost never did it completely meet my needs. I had to build my own Nix/Derivations, Nix/Overlays, etc
            • I was used to npm, Brew, cargo, pypi - these are reliably up to date and have binary builds that are typically built once by the maintainers and then available for most primary CPU Architectures.
              • Nix intentionally does not use the binaries that are already built by the maintainer you trust.
              • In that respect, it's pretty wasteful from an energy efficiency perspective.
              • Instead, it sets up a pure universe that builds everything from first principles based on its ecosystem. It's a Phrase/Boil the Ocean approach. It's admirable, perhaps, and in the asymptote it may also be the best approach (give it ten years?), but for now it's not practical for me.
          • prepared to set up your own binary Build/Farm with its own caching stratgegy and be responsible for building your dependencies.
            • this was the kicker. after using nix for two months, I suddenly found that making a small change to my configuration files required choosing between
              • A - accepting insecure, out of date dependencies
                • for example, as of the current moment, the build for mise that's available and cached for my main platforms is about a year old.
              • B - building huge dependencies
                • and potentially paying Cachix or Determinate Systems to be your personal Build/Cache - or worse, reinventing the wheel and rolling your own binary build farm

    • building a Homelab with K8s

      • eventually using DevPod for DevContainers
        • I think k8s and DevContainers are just as Compli/cat/ed as the Nix ecosystem. But in my prediction and estimation, the benefits/drawbacks are more balanced in my favor with this ecosystem. The larger tech ecosystem is dominated by Containerization, which not only means that systems are designed for these systems, but also that knowledge in that domain is more understandable to other people - the value of knowledge in this domain is not only more perceivable by others by it also more useful since more meat-space neurons have oriented themselves around it.

  • Gard/Diff

Earlier