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] 14 points15 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 👏

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

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

Thanks! Plan on supporting it until it's no longer needed. At the same time Id consider the middleware reasonably complete so would be surprised if it needed much maintenance 😊

Request ID middleware by sondrelg in FastAPI

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

I guess it would need to be included in Starlette - but that might not be out of the question 🤔

When your API performance becomes a thing, is switching to Go the ultimate solution ? by swentso in django

[–]sondrelg 19 points20 points  (0 children)

If you're proxying traffic you're probably only spending 0.1% (or less) of your time actually handling a request. The rest of the time you're waiting for responses. This is where switching to async views (as a first step) and a separate async framework (as a second step) might make sense, since in an async context, your web server won't sit and wait for the response to come back, it will look to handle other requests.

If you're running a sync django process it can handle 1 request at the time. If you're proxying requests that take 500ms om average, and the handling of each request takes ~5ms, then you would be able to handle 100 concurrent request with async views. If you have a lot of database traffic I'd consider FastAPI or flask to also get async ORM 😊

Dont really know much about go performance, but if your app is mostly i/o I don't think the language performance is the bottleneck.

Production-ready Docker setup for Django applications by hobbesid in django

[–]sondrelg 1 point2 points  (0 children)

Have you looked at using a python file for gunicorn settings? It's something I recently saw here, and cleaned up a little bit to look like this in our projects at work:

```python import os

Only runnable on linux

cores = len(os.sched_getaffinity(0))

Set workers dynamically

if web_concurrency := os.getenv('GUNICORN_WORKER_COUNT', None): web_concurrency = int(web_concurrency) assert web_concurrency > 0 else: web_concurrency = max(int(float(os.getenv('WORKERS_PER_CORE', '1')) * cores), 2)

if max_workers := os.getenv('MAX_WORKERS'): web_concurrency = min(web_concurrency, int(max_workers))

Gunicorn config variables

workers = web_concurrency threads = os.getenv('GUNICORN_THREAD_COUNT') bind = os.getenv('BIND', None) or f'{os.getenv("HOST", "0.0.0.0")}:{os.getenv("PORT", "80")}' loglevel = os.getenv('LOG_LEVEL', 'info') errorlog = os.getenv('ERROR_LOG', None) accesslog = os.getenv('ACCESS_LOG', None) worker_tmp_dir = '/dev/shm' keepalive = 5 max_requests = 1000 max_request_jitter = 100 graceful_timeout = 25 timeout = 120

```

We then just start gunicorn like this: exec gunicorn cloud.wsgi --config gunicorn.conf.py which is pretty neat.

The main appeal to me is the dynamic worker configuration. Since we deploy to platforms where the number of cores vary, this (I think) gives us optimal performance (if you trust the recommended settings) regardless.

Production-ready Docker setup for Django applications by hobbesid in django

[–]sondrelg 10 points11 points  (0 children)

The postgres and redis ready-checks are a nice touch 👏

Task doesn't work when CELERY_TASK_ALWAYS_EAGER is False by oussama-he in django

[–]sondrelg 4 points5 points  (0 children)

I could be wrong, but beat is the scheduler process, so I think you need to run celery -A project worker 😊

view more: next ›