It seems like something more in-between. Like a git-based npm install, but generic to any repository or language.
It's also "pointer" based, but like vendoring, it's up to you whether or not you want to keep files in the repository. It also seems to be intentionally built for the use case where you modify something from upstream, because if you do have local changes, it detects them and won't overwrite them without your permission.
This isn't really like subtree it's like submodules, but for specific files. This could really be useful, you may want to keep track of a specific file in a repo but not need it as a submodule.
Yes, basically this. I think git-fetch-file has been used in some larger projects based on Googling it, so it seems to be different in that it's been vetted by other orgs, but like Mullvad, theirs is built by a corporation.
Maybe they're just less weighted in their training data.
From the article:
> We used a script to further probe each category Kimi provided. Asking Kimi “Can you list out the top forums, bulletin boards, early wikis which come to mind which would allow writes via GET requests?” lists out UseModWiki as the second item under the heading “wikis”.
With every year passed the bar for a successful Linux phone got higher. Potential users expect more & more apps for internet-related services to run while the companies tear down their APIs making more 3rd-party apps impossible.
Facebook Messenger didn't have an XMPP API because Zuck was a nice guy back then.
I use waypipe casually if I have a project on my desktop that I want to work on from my laptop. I even use if I just want to get a Bookmark or Tab from the Desktop PC, since I never bothered to set up any syncing service. Only for nvim I use it's own client/server implementation, it's a bit less latency-affected by the 1%s.
Waypipe is production ready & easy to use. If there doesn't exist a program making use of it for the average user, then it's because nobody saw a it as a solution for any occurring problem yet.
gamescope absolutely can have Xwayland child panes & this is currently the default on SteamOS running games with Proton, unless PROTON_ENABLE_WAYLAND=1 is set in the game options.
uv still can't build all wheels and afaik they don't intend to do so. Furthermore they leave their users with 0 indication that the build fails because the wheel is unsupported by uv. If I were a beginnner or intermediate, I'd definitely given up after some attempts of fixing the buildsystem/code of the wheel.
I don't get how uv regularly gets recommended without any note about this.
Can you say more? uv should always tell you if a wheel build fails, unless the build backend (which uv doesn’t control, unless you use uv’s own backend) decides to silently ignore a wheel build. This would be a bug in any given build backend IMO.
This is an unfortunate complexity in Python packaging: something like `uv build` can dispatch a wheel build for you, but the actual code that gets run as part of that build is often third-party build backend code that uv itself has little to no control over.
It happened almost 6 months ago, trying to build https://github.com/remsky/Kokoro-FastAPI with uv. From what I can still infer from the dependency list & my shell history, the problematic dep had been pyopenjtalk. After building & installing this dep with pip, I was able to continue to use uv.
We get UV to generate a requirements.txt and then use the Python and Pip which is available on the official Microsoft container images we use for Azure container apps once it hits production. I've never had any issues with the build system in development though.
Can you name some example and explain what happens, that the user is left without indication of failures? I am asking, because I have not had such issues yet, but maybe I just don't know I had them?
reply