pants
nogil
Our great sponsors
pants | nogil | |
---|---|---|
34 | 31 | |
3,059 | 2,839 | |
2.5% | - | |
9.8 | 5.7 | |
7 days ago | about 1 month ago | |
Python | Python | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pants
-
Monorepo + Microservices + Dependency Managment + Build system HELL
Does pants/bazel can help me?
-
Go Dependency management in large company projects - How do you do it?
Hyper-large tech companies managing hyper-large monorepos using Bazel (google), buck (Facebook), please (thought machine), pants (Twitter, Foursquare & Square) enjoy them but also have a lot of resources devoted to running and maintaining it.
-
Reason to use other Build Tool than Make?
Yeah there's definitely some alternatives out there. Pants is another one that has a lot of traction.
-
Is it possible pickle a function with its dependencies?
You should look into pex, or itβs parent build system pants. A PEX (Python EXecutable) file can package up all your code including dependencies and run on another machine of similar OS with just an available compatible interpreter.
-
Maintain a Clean Architecture in Python with Dependency Rules
Before clicking on this, I expected to see import-linter [0] which achieves something very similar but with, in my opinion, a bit less magic. Another solution in a similar spirit is Pants [1], though this is actually a build system which allows you to constrain dependencies between different artifacts (e.g. which modules are allowed to depend on which modules).
To Sourcery's credit, their product looks much more in the realm of "developer experience" -- closer to Copilot (or what I understand of it) than to import-linter. Props to them for at least having a page about security [2] and building a solution which doesn't inherently require all of your source code to be shared with a vendor's server.
[0] https://github.com/seddonym/import-linter
[1] https://www.pantsbuild.org/
[2] https://docs.sourcery.ai/Product/Permissions-and-Security/
This has also been recently integrated in pants.
- Blazing fast CI with MicroVMs
-
Visualize your dependencies with GraphMyRepo.com
This was the fix: https://github.com/pantsbuild/pants/pull/16896
-
Better CI/CD caching with new-gen build systems
A build system is a program that orchestrates the execution of underlying tools such as compilers, code generators, test runners, linters and so on. Examples of build systems include the venerable Make, the JVM-centric Ant, Maven and Gradle, and newer systems such as Pants and Bazel (full disclosure: I am one of the maintainers of Pants).
-
Using URLs for dependency management
Pants allows you to override an artifact's URL: https://www.pantsbuild.org/docs/reference-jvm_artifact#codeurlcode
nogil
-
Our Plan for Python 3.13
This might be a dumb question, but why would removing the GIL break FFI? Is it just that existing no-GIL implementations/proposals have discarded/ignored it, or is there a fundamental requirement, e.g. C programs unavoidably interact directly with the GIL? I know that the C-API is only stable between minor releases [0] compiled in the same manner [1], so it's not like the ecosystem is dependent upon it never changing.
I cannot seem to find much discussion about this. I have found a no-GIL interpreter that works with numpy, scikit, etc. [2][3] so it doesn't seem to be a hard limit. (That said, it was not stated if that particular no-GIL implementation requires specially built versions of C-API libs or if it's a drop-in replacement.)
[0]: https://docs.python.org/3/c-api/stable.html#c-api-stability
[1]: https://docs.python.org/3/c-api/stable.html#platform-conside...
[2]: https://github.com/colesbury/nogil
[3]: https://discuss.python.org/t/pep-703-making-the-global-inter...
-
Real Multithreading Is Coming to Python
https://github.com/colesbury/nogil does manage to get rid of the GIL, but it's not certain to make it into Python core. The main problem is the amount of existing libraries that depend on the existence of the GIL without realizing it - breaking those would be extremely disruptive.
Important to note that this is different from the nogil project ( https://github.com/colesbury/nogil ) - this is about the feature that's landing soon in Python 3.12 which will allow multiple Python sub-interpreters each with their own GIL - hence enabling Python code to run multi-threaded in the same process, albeit with a fair amount of extra work to co-ordinate between those different interpreters.
The tutorial itself is fantastic - it's not an easy feature to try out right now but I got there by following the step-by-step instructions.
Also interesting is this project, linked to from the end of the tutorial: https://github.com/jsbueno/extrainterpreters
Posted my own set of short notes on my blog: https://simonwillison.net/2023/May/15/per-interpreter-gils/
-
[D] The hype around Mojo lang
CPython is also investigating the removal of the GIL (PEP703, nogil). I think requiring the GIL is a wider thing that libraries will need to address anyway. But also, for the same reason as above I'd be surprised if the Modular team thought that saying "you can run all your python code unchanged" was a good idea if there was a secret "except for code that uses numpy" muttered under the breath.
- PEP 684 was accepted β Per-interpreter GIL in Python 3.12
-
Python 3.11.0 final is now available
I'm worried about the speedup
My understanding is that it's based on the most recent attempt to remove the GIL by Sam Gross
https://github.com/colesbury/nogil
In addition to some ways to try to not have nogil have as much overhead he added a lot of unrelated speed improvements so that python without the gil would still be faster not slower in single thread mode. They seem to have merged those performance patches first that means if they add his Gil removal patches in say python 3.12 it will still be substantially slower then 3.11 although faster then 3.10. I hope that doesn't stop them from removing the gil (at least by default)
-
Faster CPython 3.12 Plan
Looks like it's still active to me:
-
As I said in the title, I had an issue but it should be solved now
But theres hope! https://github.com/colesbury/nogil
Here is a proof of concept of a promising solution to this problem: https://github.com/colesbury/nogil
-
Why did you switch from another language to Rust? Do you regret not learning it earlier?
Yes it does. It's a simple fork of CPython - for all intents and purposes it IS CPython: https://github.com/colesbury/nogil
What are some alternatives?
Bazel - a fast, scalable, multi-language and extensible build system
hpy - HPy: a better API for Python
please - High-performance extensible build system for reproducible multi-language builds.
megalinter - π¦ MegaLinter analyzes 50 languages, 22 formats, 21 tooling formats, excessive copy-pastes, spelling mistakes and security issues in your repository sources with a GitHub Action, other CI tools or locally.
pyflow - An installation and dependency system for Python
Buck - A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.
mypyc - Compile type annotated Python to fast C extensions
pyupgrade - A tool (and pre-commit hook) to automatically upgrade syntax for newer versions of the language.
Poetry - Python packaging and dependency management made easy
megalinter - π¦ Mega-Linter analyzes 49 languages, 22 formats, 21 tooling formats, excessive copy-pastes, spelling mistakes and security issues in your repository sources with a GitHub Action, other CI tools or locally. [Moved to: https://github.com/oxsecurity/megalinter]
jk - Configuration as Code with ECMAScript
numpy - The fundamental package for scientific computing with Python.