BiteCode_dev

"Handy" and "a good thing" are not the same thing.

USB and BT are security nightmares, and the browser is a fantastic sandbox. I'm pretty sure a lot of 0-days will come from there.

Unfortunatly no, plus the docs are indeed not great and the UI itself is lacking.

But yes, unlike pex, shiv works on windows.

It's very different than pyinstaller in the sense that:

- it uses a standard (the zipapp format from python stdlib)

- it assumes python is already installed (it's not stand alone)

I definitely should write on article on that on Bite Code on day. Adding it to the list.

True, for servers you can't warm up, shiv is your best bet: https://shiv.readthedocs.io/

Or points to your own private pypi instance with --index-url.

Definitely not for prod, but I used to have (and recommend: https://www.bitecode.dev/i/114175324/whats-a-good-name-for-a...) a giant venv just for my laptop scripts. Having one per script is too much, but none is inviting pain.

The problem with that is that eventually too many scripts means you will hit incompatibilities in Python where you can only install one version of a lib in each venv.

This trick is perfect because:

- From now on, I always install uv on all my machines anyway.

- After the first run, not only the cache make it fast, but it uses hard links so that you don't even pay the of multiple install on disk space (that's also how they are so fast in creating the envs, that and some interesting HTTP/zip tricks: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...).

- Deps are clearly defined in the script, so it's self-documenting.

For prod, shiv (https://shiv.readthedocs.io/) is probably your best bet but I'm betting uv will come up with a version of that soon.

`--offline` :)

Other neat tricks with uvx (uv equivalent of npx) to run one time commands in some contexts:

- alias download_mp3="uvx --no-cache --from yt-dlp[default] yt-dlp --extract-audio --audio-format mp3" to download sound from Youtube videos, SoundCloud pages, etc. This update yt-dlp every time, which is required given the counter measures change so often and the dl rarely affect the total processing time anyway (requires ffmpeg).

- "uvx --with <package> --with pyqt5 --from qtconsole jupyter qtconsole" starts a qtconsole (GUI version of ipython) with <package> installed so you can test it quickly. Temp venv, everything cached so next time it's instant, one single copy of pyqt5 for the current use no matter how many times you run those.

- "uvx --with virtualenv pipx run pipsi install nodejs-bin". Ok it's useless, but it's fun that it even works :)

uv's cache system and downloads optimization are quite smart, as Charlie marsh (astral CEO) explains in the interview: https://www.bitecode.dev/p/charlie-marsh-on-astral-uv-and-th...

Mozilla is getting a lot of criticism, but just for letsencrypt alone they are making the world a better place.

Before them I never used SSL for anything, because the cost/benefit ratio was just not there for my services.

Since then, I never not use it.

Spent the last 20 years hearing that.

At some point I think it's more honest to say "the python ecosystem keeps getting more awesome".

If you claim to do a research on coin tossing, the minimum is to be aware on how people toss coin.

The whole purpose of tossing a coin is randomness, so of course you want high and fast.

If the result was that no matter how high and fast you throw is you get this bias, it would have been interesting.

But now you just say "if you do things badly, things don't work".

I'm sure you will find similar behavior with dice if you just gently let them fall from your hands instead of throwing them across the table.

This is silly.

Someone, somewhere will eventually find a legitimate use case for it.

That's not tossing a coin, that's barely throwing it in the air.

To me this kills the credibility of the entire study and of the authors.

Sure, there may be something to it, but people will have a very different thing on their mind unless they check the video, which I wouldn't have done without your prompting.

It's unlikely they don't understand how misleading it is.

And somehow I have the intuition a proper coin toss will not exhibit the same properties.

I'm editing the transcript right now, and he says it's more about exposing a nice API to the user.

E.G: Clickhouse interval support, which is an important type for observability, was lacking. You couldn't subtract datetimes to get an interval. If you'd compared 2 milliseconds intervals to one second ones, it wouldn't look at the unit and would say 2 ms is bigger, etc. So he had to go to the dev team, and after enough back and forth, instead of fixing it, they decided to return an error and he had to insist for a long time until they actually implemented a proper solution.

Quoting him "But like these endless issues with ClickHouse's flavor of SQL were problematic."

Another problem seemed to be that to benefit from very big scaling with things like data in Parquet at rest + local cache meant basically leaking all your money to AWS because the self-hosted version didn't expose a way to do that yourself. Click house scales fine at my size, so I can only trust him on that front since I'm nowhere that big.

Funnily after that, they moved to TimeScale, and the perfs wouldn't work for their use case.

They landed on DataFusion after a lot of trials and errors.

But really interesting perspective on the whole thing, you can see he is kinda obsessed with the user experience. The guy wrote a popular marshmallow alternative, 2 popular celery alternative and one watchdog popular alternative, all FOSS.

These kind of people are the source of all imposter syndrome in the world.

I'll publish that video next week on Bite Code if I can. If I can't, it will have to wait 3 weeks cause I'm leaving for a bit. But Charlie Marsh's one (uv's author) is up, if you are into overachievers.

I echo other's sentiment, ClickHouse is much more performant than TimeScale.

Interestingly, I recently interviewed Samuel Colvin, Pydantic's author, and he said when designing his observability Saas called LogFire, he tried multiple backends, including ClickHouse.

But it didn't work out.

One of the reasons is LogFire allows the users to fetch the service data with arbitrary SQL queries.

So they had to build their own backend in rust, on top of DataFusion.

I used ClickHouse myself and it's been nice, but it's easy when you get to decide what schema you need yourself. For small to medium needs, this plus Grafana works well.

But I must admit that the plug and play aspect of great services like Sentry or LogFire make it so easy to setup it's tempting to skip the whole self hosting. They are not that expensive (unlike datadog), and maintaining your observability code is not free.

I just checked, and there is indeed a `--pex-root` option with and even "-c" to specify a custom entry point.

Thanks for pointing it out.

It would today, because macos requires signing, and windows has "the mark of the web".

They don't apply to scripts, so Python is fine, but they do apply to executables.

Having to sign your zip every time you produce it would nullify the benefit of the concept. And because the checksum of the executable file change according to the content of the zip, you can't just sign the cosmopolitan part.

That's a cool idea.

Wonder what the FUSE equivalent for windows is.

It can, but:

- It's slow.

- The underlying python code cannot use open() to access its own resources, but must use pkg_resources, and most packages on pypi don't do that because most dev don't even know it exists or what problem is soves.

- _ _ file _ _ is not available, breaking a lot of things. zip_safe is a build option, but actual compliance to it is hard work and rare.

pipx is orthogonal to the problem pex and shiv are solving since:

- it doesn't provide a single file for a full project with all dependencies.

- it requires internet access on the target machine to install things.

- it can't give you access to underlying API for things like wsgi.

- it requires pipx on the target machine.

- it requires a wheels made from a build, which many projects don't have (such as a lot of web projects).

I know it's not very nice to post that here, but given it's hard to get good info about python because the ecosystem is so huge, I'd rather give it straight:

Don't use pex, use shiv: https://shiv.readthedocs.io/

Pex doesn't work on windows, is slower than shiv and shiv solves the resource files problem that you will encounter with dependencies like django. To achieve this, shiv unzips the whole zipapp in a cache on disk and create a transparent proxy to it.

Still, I wish zipapps had better tooling honestly. Using either pex or shiv is more complex than it needs to be.

I hope uv will eventually give you something like "uv zipapp" and make it good and simple.

Right now, to bundle all deps for shiv you have to download first all wheels, then figure out the proper incantation to include them. And if you use WSGI, you probably want some kind of dedicated entry point.

The tech is cool, but it deserves maturing to be a true ".war for python".

It totally does make the distinction.

If you use cookies for auth, no need to disclail it.

Better, you don't need a banner even of you do track users for anybody with DNT. So you can offer a seamless experience.

They just don't care.

I'm with @belval on this one, it's ok to prioritize github, but people that want the standard to implement an alternative should not feel like they are doing something that may not be supported.

It kinda feels like that right now.

Of course, the scammers have created their own AI to call people and scam them so it's just playing catchup.

It's like corporate avatars for hiring or cold call bots for sales.

I'd say stick to white listed numbers, but pro phones can't do that, and they are the most prone to spam.

I'm already surprised that they are not looking at the number, realizing that pilots cost much less to train than planes to build, and draw conclusions from there. The army has been more cynical in the past.

Thanks for reminding me of :~:text=.

Switching a pawn to a queen is going to require some creativity :)

Usually this joke flies but apparently, after the last election, people seem to take it seriously.

Yes, but:

- You don't have full control over the knife. In fact it's not about your use of the knife.

- The people in control of the knife have a poor track record at caring about you, and belong to a category that history has proven we should not trust.

- Every time you use the knife, you sign a blank contract giving full authorization to future non-specified knife usage to people you don't know nor do you know their motive. And you trust none of those people, for an indefinite length of time, will abuse it.

- Cumulative use of the knife can accumulate stabs that may be delt to you and all your love ones one day all at once.

- Use of knife can be automated and scale at the level of all countries.

- Most people are not knowledgeable about the knife, don't know much about it, and it's invisible to them.

"He already has pneumonia, adding lung cancer doesn't matter"