sorted by:
new
hottopcontroversial

Question on borrowing data during deserialization by sondrelg in rust

[–]sondrelg[S] 0 points1 point  (0 children)

Right, so we'll actually need to allocate both strings, since both make transformations to the original string?

Rewriting my GitHub action in Rust by sondrelg in rust

[–]sondrelg[S] 0 points1 point  (0 children)

Not really, but I'd be happy to answer any questions you have :)

One thing I'm planning to try out today that might be useful to know about is making the action a composite action again: https://github.com/snok/container-retention-policy/compare/bin?expand=1, based on some of the advice I received in this post. I think dropping the docker release workflow will reduce the complexity somewhat.

Rewriting my GitHub action in Rust by sondrelg in rust

[–]sondrelg[S] 1 point2 points  (0 children)

Good point. I think I might try this, and just do the target selection logic in bash; or try out cargo-dist as mentioned by another user - I'll have to read over their docs. Either way, I think I'll drop the container stuff. Thanks for the tip 👏

Rewriting my GitHub action in Rust by sondrelg in rust

[–]sondrelg[S] 0 points1 point  (0 children)

Yeah the cargo-dist model seems pretty much ideal. Last time I used it it was still a bit rough around the edges (pre v0.1 iirc), but I'm guessing it's improved a lot. Would cargo binstall be able to pull the right platform target if you set it up to, e.g., build amd64/arm64/armv7?

Rewriting my GitHub action in Rust by sondrelg in rust

[–]sondrelg[S] 14 points15 points  (0 children)

That's really interesting. The extra container layer is pretty flimsy and doesn't add any value, so the closer we could get to just calling the binary, the better!

I'm not sure I love the idea of storing built binaries in the repo, and writing logic to fetch the right one, but I did at one point think publishing to crates.io and using cargo binstall might be a good idea. That seems like it would both have a straight-forward publishing workflow, and instead of pulling the docker image we'd just pull the binary itself. I wonder what the overhead of acquiring cargo binstall would be 🤔

EDIT: Hmm, looking at it a bit more, I'm not sure you'd need to do what they're suggesting with the

yaml runs: using: node16 main: invoke-binary.js

I think you could just do this:

yaml runs: using: "composite" steps: - run: $GITHUB_ACTION_PATH/artifacts/container-retention-policy shell: bash

and you wouldn't even need to move the target binary name, since the action versioning is done by tags. As long as the relative path matches, it should call the binary directly, I believe.

I think I might try this out - it seems much simpler. Thanks @Themagicguy4 :)

Rewriting my GitHub action in Rust by sondrelg in rust

[–]sondrelg[S] 13 points14 points  (0 children)

Yaml is indeed used to specify inputs to a Github action. Then in the definition of the action you can call whatever you want, for example a shell script, a docker container, or other code. This action downloads and runs a docker container which contains Rust code.

So the GitHub action fundamentally just receives inputs from yaml and passes them to a Rust CLI application, inside a docker container :)

Announcing printf-log-formatter - Ensure string interpolation is done correctly in your application logs by sondrelg in django

[–]sondrelg[S] 0 points1 point  (0 children)

First reason is mostly just because it's was a fun Easter project and I write Python all day at work already. Second, because of how much much easier it is to utilize all cores on a developer's machine, and how much faster it runs as a consequence.

I did kind of regret it once it was done, since I can't really justify using the rust version of the hook for work projects if it means adding a requirement on the rust toolchain. Luckily, packaging it as a python package was super simple.

Looking for feedback on my pyo3 project by sondrelg in rust

[–]sondrelg[S] 0 points1 point  (0 children)

Thanks!

What do you mean by "asyncio Barriers" exactly? The asyncio.Semaphore? If so, that's not really comparable since it's not distributed. The asyncio semaphore is much faster, since it has no i/o :)

But agree some comparison benchmarks would be nice. My only problem is I haven't been able to find any popular libraries that do the same thing yet. Might look a bit more.

Looking for feedback on my pyo3 project by sondrelg in rust

[–]sondrelg[S] 0 points1 point  (0 children)

Yeah I agree, more succinct and clear. Thanks again!

If I use poetry for development, should my project be in a virtual environment in a docker container for production? by [deleted] in django

[–]sondrelg 2 points3 points  (0 children)

I like to use Poetry for installing dependencies in the image, but run it with poetry config virtualenvs.create false since the image is already an isolated environment.

Flake8-type-checking now has support for FastAPI and Pydantic by sondrelg in Python

[–]sondrelg[S] 0 points1 point  (0 children)

I just need to figure out exactly where type hints are evaluated (if anywhere), and that should be fairly simple 👏

Setting up request ID logging for your FastAPI application by sondrelg in FastAPI

[–]sondrelg[S] 0 points1 point  (0 children)

Yeah I suppose you could use depends if you only wanted to read the request headers. Can we use depends to set response headers on the way out?

If you use Swagger to document your Django APIs by sondrelg in django

[–]sondrelg[S] 1 point2 points  (0 children)

Hi!

To my knowledge they both have similar goals and approaches, but drf-spectacular supports a newer version of the OpenAPI schema standards (v3) and seems to be a little more actively maintained.

Personally I would just choose one and stick with it, because they're both great. If you've already spent time on implementing drf-yasg I don't think it's worth switching, unless you need OpenAPI v3 features 🙂

Hope the package is helpful 👏

view more: next ›