Build targets?

[frenata]

Is there interest in adapting una so users can specify a build target other than a wheel?

I'm imagining use cases like: directly building a docker image for each app, or building a lambda layer for each lib and a lambda function for each app, etc.

Or do you think there's too much variability to make this worth it and want to keep una focused on producing easy wheels?

[carderne]

Hey @frenata, not at all opposed in theory, but would be interested to hear how you think this might work?

My idea with this tool is that once you have a wheel, creating a Docker image is quite straight forward. I haven't used Lambda enough to know what what that entails.

And right now it's basically just ~100 lines of Hatch plugin code, I wonder how much more complex it would need to be to support other use cases? But definitely interested to hear ideas!

(I haven't had time to think about this tool for several weeks but I'm expecting that to change in the next few weeks, would like to get this to a more user-friendly state.)

[frenata]

(I haven't had time to think about this tool for several weeks but I'm expecting that to change in the next few weeks, would like to get this to a more user-friendly state.)

It feels like this is the key missing piece on top of uv, so I look forward to it (and am happy to potentially help too).

I haven't used Lambda enough to know what what that entails.

I haven't hacked on una+lambda yet, but I will at least by this weekend. Lambda basically wants a zip distribution. In principle this can include all of your dependencies, but the better way, especially with a monorepo IMO, would be to ship each una libs project as a "lambda layer", which is basically just its own zip. Then lambda itself handles mashing layers together.

From a build tool / monorepo perspective, all this really means is that I'd want the ability to produce a libs wheel by itself (I assume una supports this) and also the ability to produce an apps wheel without having the internal libs bundled with it, since Lambda's runtime will handle that. That'll have the nice property that in a semi complicated monorepo, you could make a change to a lib: run lib tests, app integration tests (to make sure it doesn't break the callers) and then just build/deploy the lib as a lambda layer -- no deploy necessary to the apps, other than a version bump.

[carderne]

Hey @frenata are you still interested in this?

I've been playing around more with uv since it added uv sync --all-packages and I'm not sure una is needed any more.

I put together a repo at carderne/postmodern-mono that has a lib and two apps, one with a Dockerfile. It seems to work pretty well just with uv...

I haven't been thinking about this for 3-4 months so there might be something I'm missing or forgetting, but I'm leaning towards scrapping una and just using that setup.

[frenata]

I've been exploring uv mostly solo for now -- a past colleague was interested in the graph visuals (they're using rye rather than uv directly though). I think you're probably right that what you were trying to do is more of a pattern than another tool, so appreciate the link.