#pixi — Public Fediverse posts

Apropos Kinder und Datenschutz bzw. Privatsphäre: es gibt ein Pixi, das erklärt was "privat" eigentlich bedeuten soll.

Bekommt man kostenlos bei der/dem BfDi: https://www.bfdi.bund.de/SharedDocs/Videos/DE/Pixi/das-ist-privat.html
#dcoghh #bfdi #pixi #privat

Apropos Kinder und Datenschutz bzw. Privatsphäre: es gibt ein Pixi, das erklärt was "privat" eigentlich bedeuten soll.

Bekommt man kostenlos bei der/dem BfDi: https://www.bfdi.bund.de/SharedDocs/Videos/DE/Pixi/das-ist-privat.html
#dcoghh #bfdi #pixi #privat

art of my amber isle dino, pixi candyvore the yutyrannus, and my favorite villager and crafting item. :3 // art backlog.

#pumpkiniumart #art #furry #dinosaur #amberisle #pixi #cecil #coelacanth #yutyrannus #brachiosaurus #candycorn

Yesterday was just a fantastic day for me. I planned to post on it. Just overjoyed. Strongly tempered today by the acquisition of Astral, and therefore the uncertain future of #uv and #ty (and transitively, #pixi).

I’m gonna focus on yesterday.

#jouRapNal #book18 day 87

20260310Tue

#3goodThings #pixi #bedCorner #escooter #threeGoodThings

#appointment #rain #heldOff

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HotTo

@bfdi
Och nö. Warum kann man als Privatperson eure tollen Pixi-Bücher nicht mehr bestellen? Dann ist wohl klar, warum ich seit drei Monaten vergebens auf die Zustellung warte. 😥

#Pixi #BfDI #kostenlos

My first article for Towards Data Science!

How sharded repodata (CEP-16) makes conda and Pixi 10x faster with 90% less bandwidth on conda-forge.

Thanks to Bas Zalmstra, @dholth, and the teams at @prefix, Anaconda, and Quansight.
https://towardsdatascience.com/why-package-installs-are-slow-and-how-to-fix-it/

#PackageManagement #OpenSource #Python #Conda #Pixi #DataScience

My first article for Towards Data Science!

How sharded repodata (CEP-16) makes conda and Pixi 10x faster with 90% less bandwidth on conda-forge.

Thanks to Bas Zalmstra, @dholth, and the teams at @prefix, Anaconda, and Quansight.
https://towardsdatascience.com/why-package-installs-are-slow-and-how-to-fix-it/

#PackageManagement #OpenSource #Python #Conda #Pixi #DataScience

#jouRapNal #book18 day 28

20260110

#3goodThings #dungeonsAndDrragons #Pixi #Mini #threeGoodThings

#Library #tail #pretty

#jouRapNal #book18 day 24

20260106

#3goodThings #cat #buttHairs #bath #threeGoodThings

#moli #pixi #mini

#jouRapNal #book18 day 24

20260106

#3goodThings #cat #buttHairs #bath #threeGoodThings

#moli #pixi #mini

The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.

If you're not using using `direnv` yet, you are doing yourself a disservice.

The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.

If you're not using using `direnv` yet, you are doing yourself a disservice.

The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.

If you're not using using `direnv` yet, you are doing yourself a disservice.

The more I learn about #Direnv, the happier I become. It **already** works with #Pixi. It **already** helps you with secrets (ignore `.envrc` in your `.gitignore` or equivalent). I grabbed a `layout_uv` from the direnv wiki (made some small modifications), and it works basically everywhere I want it.

If you're not using using `direnv` yet, you are doing yourself a disservice.

Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)

Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)

Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)

Here’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)

RE: https://mastodon.social/@digiresacademy/115702812560956273

I attended the dry-run of this course* recently and it was pretty mind-blowing - I'd seen before how #pixi can be used for python packaging but this course introduced me to a few new example use cases:

- Reproducible data analysis in #R
- A new application in #C
-Image processing with #Python
- #Jupyter Notebook for exploratory analysis

RE: https://mastodon.social/@digiresacademy/115702812560956273

I attended the dry-run of this course* recently and it was pretty mind-blowing - I'd seen before how #pixi can be used for python packaging but this course introduced me to a few new example use cases:

- Reproducible data analysis in #R
- A new application in #C
-Image processing with #Python
- #Jupyter Notebook for exploratory analysis

I am really enjoying the Pixi package manager, https://pixi.sh , made by @prefix. We have been using conda at my work for managing the dependencies of our python application. It involves scientific data analysis so there are lots of dependencies, and it has been a challenge to keep things up to date. Pixi has nice support for cleanly defining the direct dependencies in the pixi.toml file, and then it automatically generates a lock file. There is a command to upgrade all the dependencies too. It's amazing! I'm just starting to use it, but it is helpful so far.

#conda
#packageManagement
#pixi
#dependencyManagement

I am really enjoying the Pixi package manager, https://pixi.sh , made by @prefix. We have been using conda at my work for managing the dependencies of our python application. It involves scientific data analysis so there are lots of dependencies, and it has been a challenge to keep things up to date. Pixi has nice support for cleanly defining the direct dependencies in the pixi.toml file, and then it automatically generates a lock file. There is a command to upgrade all the dependencies too. It's amazing! I'm just starting to use it, but it is helpful so far.

#conda
#packageManagement
#pixi
#dependencyManagement

I am really enjoying the Pixi package manager, https://pixi.sh , made by @prefix. We have been using conda at my work for managing the dependencies of our python application. It involves scientific data analysis so there are lots of dependencies, and it has been a challenge to keep things up to date. Pixi has nice support for cleanly defining the direct dependencies in the pixi.toml file, and then it automatically generates a lock file. There is a command to upgrade all the dependencies too. It's amazing! I'm just starting to use it, but it is helpful so far.

#conda
#packageManagement
#pixi
#dependencyManagement

I am really enjoying the Pixi package manager, https://pixi.sh , made by @prefix. We have been using conda at my work for managing the dependencies of our python application. It involves scientific data analysis so there are lots of dependencies, and it has been a challenge to keep things up to date. Pixi has nice support for cleanly defining the direct dependencies in the pixi.toml file, and then it automatically generates a lock file. There is a command to upgrade all the dependencies too. It's amazing! I'm just starting to use it, but it is helpful so far.

#conda
#packageManagement
#pixi
#dependencyManagement

I am really enjoying the Pixi package manager, https://pixi.sh , made by @prefix. We have been using conda at my work for managing the dependencies of our python application. It involves scientific data analysis so there are lots of dependencies, and it has been a challenge to keep things up to date. Pixi has nice support for cleanly defining the direct dependencies in the pixi.toml file, and then it automatically generates a lock file. There is a command to upgrade all the dependencies too. It's amazing! I'm just starting to use it, but it is helpful so far.

#conda
#packageManagement
#pixi
#dependencyManagement

I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.

I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.

#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!

Habt ihr das schon gesehen?

Finde nur ich das krass?
Eigentlich finde ich das sogar skandalös!

Warum?!?!

#fedieltern #Pixi #carlsen #buch #lesen #lesefoerderung

#Nix: "yeah we FOD and sandbox, and inshallah we'll switch from namespaces to ephemeral VMs, but bitwise reproducibility? Well the .iso yes, but actually not really, no can do, sorry. Maybe write a deterministic emulator of the kernel?"

Cond... #Pixi: "yo just SAT faster and lock your lock-files, it 'ensure bit-by-bit #reproducibility across platforms', I swear on me mother" https://arxiv.org/abs/2511.04827

#Nix: "yeah we FOD and sandbox, and inshallah we'll switch from namespaces to ephemeral VMs, but bitwise reproducibility? Well the .iso yes, but actually not really, no can do, sorry. Maybe write a deterministic emulator of the kernel?"

Cond... #Pixi: "yo just SAT faster and lock your lock-files, it 'ensure bit-by-bit #reproducibility across platforms', I swear on me mother" https://arxiv.org/abs/2511.04827

@Geeky_sebastian #uv solves problems for me. It solves them better than everything else I’ve tried. I like what Charlie Marsh has to say. I don’t anticipate having to pivot; but if I do, I do. By the way, uv hasn’t replaced #pixi for me.

Two weeks out from #SciPy2025 and we’re still buzzing ⚡

🛠️ Our packaging workshop with #Hatch + #UV made best practices feel doable
💬 60+ joined our “Packaging Pain Points” BoF—real talk, real momentum
🚀 30+ PRs opened in one day—many from first-timers!
🎙️ Lightning talks, #Pixi demos, and a SciPy Song shoutout!

More soon—including our Aug 7 event on peer review w/ Stanford #OSPO.

✨ Read more: https://www.pyopensci.org/blog/pyopensci-at-scipy-2025

#Python #OpenSource #OpenScience #ResearchSoftware #CommunityDriven

Update auf Version 1.19.2.6 für Pokémon Unite angekündigt

Das Balancing der spielbaren Pokémon wird wieder angepasst.

Zur News: https://news.bisafans.de/11811

#Glurak #Relaxo #Pixi #Update #Knakrack #Hoopa #Patch #IOS #Android #HoOh #Garados #Lahmus #Guardevoir #Enton #NintendoSwitch #Fruyal #Pokusan #Intelleon #Liberlo #PokémonUnite #Castellith

Update auf Version 1.19.2.6 für Pokémon Unite angekündigt

Das Balancing der spielbaren Pokémon wird wieder angepasst.

Zur News: https://news.bisafans.de/11811

#Glurak #Relaxo #Pixi #Update #Knakrack #Hoopa #Patch #IOS #Android #HoOh #Garados #Lahmus #Guardevoir #Enton #NintendoSwitch #Fruyal #Pokusan #Intelleon #Liberlo #PokémonUnite #Castellith

Neulich im #Kindergarten. Gespräch mit der Leitung. Wir kommen auf das Thema #Datenschutz. Spüre Interesse und verweise darauf die #Pixi-Bücher des @bfdi, die unter der Leitung von @ulrichkelber eingeführt wurden, in großen Mengen bestellen zu können.
Zwei Wochen später sind die Heftchen zum mitnehmen ausgelegt und am Nachmittag fast alle vergriffen :ablobcatheartsqueeze: nun kann die Kindergeschichte bei den Eltern wirken

#TeamDatenschutz ins #Kinderzimmer, liebe @fedieltern

#Nudging

Learning in action at #SciPy2025! 👀

Yesterday’s #Pixi workshop showed how to mix conda + pip, simplify ML workflows, and speed up training on cloud or GPU—fast and reproducible.

Thanks to Matthew Feickert, Ruben Arts, and John Kirkham!

We’re back this morning with our packaging workshop. Come demystify #Python packaging: https://lnkd.in/eBk5cz6i

#opensource #MachineLearning

Wissen Sie noch, welches Ihr erstes #Pixi-Buch war? Wir nicht – aber wir wissen, welches Ihr nächstes sein könnte. 😊 Pünktlich zum heutigen #Weltkindertag gibt’s unser erstes eigenes Pixi – mit spannender Story für die Kleinen und Einblicken in unsere Arbeit für gutes Leben in Stadt und Land!

Hier können Sie unser #BMWSB-Pixi kostenlos bestellen - dann ist es schon bald in Ihrem Briefkasten 👉 https://www.publikationen-bundesregierung.de/pp-de/publikationssuche/hanna-und-jacob-und-das-stadt-land-fest-2348860

I like the command-line. I’m forced to use #windows. #windowsterminalpreview is pretty nice. I have menu items for #gitbash, for #ubuntu under #wsl, for cmd.exe, for #powershell, #azure, and #anaconda. I do a little editing here in actual #Vim but mostly I use #PyCharm and #ideavim. I do all my #git commands in the terminal. Same with #pixi though in my situation it’s often convenient to use pixi from cmd.exe. This toot is a strong recommendation for Windows Terminal Preview.

I like the command-line. I’m forced to use #windows. #windowsterminalpreview is pretty nice. I have menu items for #gitbash, for #ubuntu under #wsl, for cmd.exe, for #powershell, #azure, and #anaconda. I do a little editing here in actual #Vim but mostly I use #PyCharm and #ideavim. I do all my #git commands in the terminal. Same with #pixi though in my situation it’s often convenient to use pixi from cmd.exe. This toot is a strong recommendation for Windows Terminal Preview.

#RÜCKRUF | #WARNUNG | Aufgrund besonderer Veranlassung: Aktuelle #Verbraucherinformation von #CARLSEN (#Baby-#Pixi-Bücher > 'Überdosis' #Bisphenol A)
https://www.carlsen.de/faq-zur-ruecknahme-von-2-baby-pixi-unkaputtbar-aus-der-1-druckauflage-2023

Fundstellen zu Rückrufaktionen & mehr:
https://www.produktrueckrufe.info/

#RÜCKRUF | #WARNUNG | Aufgrund besonderer Veranlassung: Aktuelle #Verbraucherinformation von #CARLSEN (#Baby-#Pixi-Bücher > 'Überdosis' #Bisphenol A)
https://www.carlsen.de/faq-zur-ruecknahme-von-2-baby-pixi-unkaputtbar-aus-der-1-druckauflage-2023

Fundstellen zu Rückrufaktionen & mehr:
https://www.produktrueckrufe.info/

#ThisMonthInFluiddyn - Jan 2024 edition

Plenty on the packaging front this time.

🔹Ported to #pdm as packaging tool for most of our projects.

🔹Trying out #pixi as an alternative to #conda / #mamba. Lock files are great, but we had some hiccups.

https://foss.heptapod.net/fluiddyn/fluidsim/-/blob/cc2b4f9a644d41a224b1053c046f323591df809d/pixi.toml#L1-6

🔹#transonic has implemented an experimental support for #meson and #MesonPython. Unreleased and nothing final yet, but tests on #fluidsim and discussion at #Pythran is ongoing.

https://github.com/serge-sans-paille/pythran/issues/2170

#Python #fluiddyn

#ThisMonthInFluiddyn - Jan 2024 edition

Plenty on the packaging front this time.

🔹Ported to #pdm as packaging tool for most of our projects.

🔹Trying out #pixi as an alternative to #conda / #mamba. Lock files are great, but we had some hiccups.

https://foss.heptapod.net/fluiddyn/fluidsim/-/blob/cc2b4f9a644d41a224b1053c046f323591df809d/pixi.toml#L1-6

🔹#transonic has implemented an experimental support for #meson and #MesonPython. Unreleased and nothing final yet, but tests on #fluidsim and discussion at #Pythran is ongoing.

https://github.com/serge-sans-paille/pythran/issues/2170

#Python #fluiddyn