This just reeks to me of bad practice. Why use this as opposed to breaking your change into smaller PRs and merging them individually behind a feature flag or similar? With this, you have a marginally better UX for reviewing through the Github website, but the underlying issues are the same. The change being introduced is not sufficiently testable by itself, or it's (somehow) too tightly coupled to other parts of the UI/codebase that it can't be split. You still need to test for integration issues at every point of the stack, and some architecture issues or points of code reuse can't be seen from stacked changes like this.
Not for me, but I'm glad it fits other people's workflows. I just hope it doesn't encourage people to try make poorly reasoned changes!
When I've reached for stacked PRs (in the past, not using this feature) it's precisely because I've split my change into smaller PRs being merged individually.
I've just written those smaller PRs at once, or in quick enough succession that the previous PRs weren't merged before the later ones were ready. And the later ones relied on the previous ones because that's how working on a feature works.
The earlier PRs are absolutely reviewable and testable without relying on the later ones. The later ones are just treating the earlier ones as part of the codebase. I.e. everything here looks like two different PRs except the timing.
An obvious example would be "implement API for a feature" and then "implement UI that uses that API". Two different PRs. The second fundamentally relies on the first.
This is a perfect example that I've often seen in practice. There's nothing blocking in this workflow at all, and no reason these changes cannot be made in independent changes. e.g.
1) API implementation - Including tests and docs this should be perfectly acceptable to merge and review independently
2) UX implementation - Feature flagged, dummy API responses, easy to merge + review
3) One quick "glue" PR where the feature can be integration tested etc
This prevents awful merge conflicts, multiple rounds of increasingly complex stacked reviews, and a host of other annoyances.
Is there any reason that the stacked PR workflow is better that I'm ignoring or overlooking?
You're creating more work for no reason. There is absolutely no reason to make dummy API responses, a feature flag (well unless you want to delay public release of the features - domain dependent here), or a glue PR.
Moreover you haven't even eliminated the dependency. The UI PR requires knowing that the dummy API responses you've created fit the right format - i.e. approval of the API PR up to small nits.
Just test against the actual implementation from the start. Even without stacked PRs just leave the second as a draft with both sets of commits until the first is merged then rebase and make it.
Stacked PRs are superior here because they eliminate that extra work of the draft PR and parallelize the review process slightly better.
I do this as well, but there is a workflow problem to solve and that is: getting PRs merged when they need to be to continue working.
It's not a simple problem to solve, we can't all just jump because someone finished some work after all. But if the PRs are OK to rubber stamp, and merge, and they're safely behind a feature flag, then it could just be as simple as letting the submitter merge without the need for an extra review. That can of course be contentious, but then we can ask "why not?" and figure out what non-human gateways need to be added to help make it possible etc.
I'm finding myself increasingly interested in understanding what friction can be removed from the software review, merge and release process, without sacrificing safe, well tested, understandable code that follows good standards.
Super interesting, thanks! I didn't think about how this issue could easily point to a major improvement that could be made on the package manager level. Unfortunate that in Python land only Conda supports it though. It looks from the docs that uv may also support it? https://docs.astral.sh/uv/concepts/cache/#cache-directory
> It looks from the docs that uv may also support it?
I was just repeating what chatgpt told me - that uv does the same thing as npm. The documentation wasn't clear about exactly what it does either. So I had to confirm it using strace. You are indeed correct. UV does hardlink the dependencies from the global cache to the project venv. So that's good!
There's just one caveat. Hardlinking is not possible if the project and the cache are on different file systems. Even btrfs subvolume mounts from a single physical volume is considered as different filesystems. I think pnpm quite happily symlinks it instead of hardlinking it when such a situation arises (I'm not sure though. Need to check that as well.) UV doesn't do that. It complains (prints a warning) and just copies the entire thing over to the venv. So you won't get that advantage with uv if the venv and the cache are on different filesystems (like in my system). I don't know how many developers actually deal with this problem.
Hey, I'm Conor, a software engineer specializing in the backend, but capable of using whatever technologies required to get a problem solved. I have experience with large multinationals, but much prefer my time working with startups. I was the first hire in my current company, and am now looking for a new opportunity having helped the company find product/market fit, scale the solution, and reach a position of stability. Most of my details can be found on my LinkedIn, including links to my Github, Blog, and other technical works.
I am a software engineer specializing in Python backends, but have demonstrated ability using whatever technology necessary to best solve the problem at hand. I have experience working with large multinationals, and startups, both in person and on a remote-only basis. My current role is fully remote, and involves software architecture/design decisions, PoC prototyping, DevOps, improving developer tooling, and general purpose programming.
The best place to see my professional experience is on LinkedIn, but feel free to reach out to me by any means you prefer so we can discuss opportunities.
Another interesting thing in this space is Traindown[1]. It's simply Markdown for your exercises. As an example for those who need convincing to go to a link, this could be a simple workout:
It's much more free-form than this, which is a bonus for me and allows me to track metadata such as weight, time of day I'm exercising at, or general mood/feeling about the workout. I can ultimately just take these plain markdown files from the app (I use a basic Android app that visualizes this Markdown[2]), import them and do whatever processing I like in Python.
Interesting. I wrote a small program some time ago that would have needed it... well i am needing the workout... so i should go and refactor the app instead of refactoring the body...
There it is! I've been looking for something like this!
I've been using my own homebrewed toml spec, but since I am more experienced with code than training, I was concerned if it would still work well as I become more experienced. Not sure if I'll use this, but good to see another interpretation of this kind of data!
I expressed myself too succinctly and without context, sorry.
I meant we need a new DSL better suited for prompt engg, and a UI that better supports longer strings. Actualy this UI can be something compatible with Python.
But overall a reimagination of the dev experience is what I am getting at (like Jupyter for LLMs).
1) Can you get the actual code output or will this end up calling OpenAI each function call?
2) What latency does it add? What about token usage?
3) Is the functionality deterministic?
1) The OpenAI API will be queried each time a "prompt-function" is called in python code. If you provide the `functions` argument in order to use function-calling then magentic will not execute the function the LLM has chosen, instead it returns a `FunctionCall` instance which you can validate before calling.
2) I haven't measured additional latency but it should be negligible in comparison to the speed of generation of the LLM. And since it makes it easy to use streaming and async functions you might be able to achieve much faster generation speeds overall - see the Async section in the README. Token usage should also be a negligible change from calling the OpenAI API directly - the only "prompting" magentic does currently is in naming the functions sent to OpenAI, all other input tokens are written by the user. A user switching from explicitly defining the output schema in the prompt to using function-calling via magentic might actually save a few tokens.
3) Functionality is not deterministic, even with `temperature=0`, but since we're working with python functions one option is to just add the `@cache` decorator. This would save you tokens and time when calling the same prompt-function with the same inputs.
- Getting familiar with new APIs
- Bouncing general knowledge questions off it
- Having "discussions" to interact with it in a Socratic style
- Giving some "personality" to automated services by calling it as an API
2) Thanks for the pointers! Will check them out today!
Not for me, but I'm glad it fits other people's workflows. I just hope it doesn't encourage people to try make poorly reasoned changes!