I've had this experience with a bunch of popular Django-related projects recently, where they stop receiving regular PR review and releases. Keeping up with Django's release cycle then requires digging into the bug trackers and forks for common dependencies. It's totally understandable for that to happen, when even popular projects rely on the volunteer effort of one or two people.
One model I'm curious about is https://jazzband.co/, "a collaborative community to share the responsibility of maintaining Python-based projects." Not sure how well that works in practice, but it would be great for something like that to crack the maintainer-burnout problem.
I believe something like the model followed by Apache Software Foundation works well in favor of continuity of a project. They have an overseeing committee that one can request to add new committers or even transfer ownership of project if the existing committers are no longer maintaining the project.
But ASF does come with a lot of bureaucracy for creating a new project. GitHub makes creating new projects very simple but it also makes disapperance of ownership very likely. If there was a way to request GitHub to transfer ownership of a popular but unmaintained project to someone else, a lot of time and effort spent in creating new forks and new project resources could be avoided.
One thing which would help would be corporate support. The Django project itself gets some support, probably not enough, but many people forget how much of the value from Django comes from the apps rather than the core framework.
> On some Python 3 distributions, you may need to replace pip with pip3 in the command above.
Are there any distributions where the command pip just works with Python 3?
In every Python 3 installation I have used, I had to invoke it as pip3. So it seems to me that pip3 is the commonly used command and one may need to replace pip3 with pip only on some distributions.
AFAIK you usually have pip (system default python), pip2 (corresponds to python2), and pip3 (corresponds to python3). Like others have mentioned, a few distributions have python 3 as the default python.
In later versions you can invoke pip using python -m pip install ..., which makes it more clear which python is being used.
Try `PYTHON -m MODULE` as in `python3 -m pip` if you want to make sure to use python3's pip, `python2 -m pip` for python2, `~/bin/python -m pip` for a personal python install, etc.
I am aware of that. So has been many other distributions like Debian, Ubuntu, etc.
My point was: Which command do you normally use to install packages in Python 3? pip3 or pip?
I thought it was pip3 but the article seems to imply that using the pip command to install packages in Python 3 is common too. If this is true, which distribution ships Python 3 with pip instead of pip3 for installing packages in Python 3? Does it not conflict with pip of Python 2?
$ python2 -m pip ... # If you want to be sure is using Python 2
$ python3 -m pip ... # Use Python 3
$ python3 -m venv ... # Create a virtualenv with Python 3 as documented on https://docs.python.org/3/library/venv.html to "prevent any potential confusion as to which Python interpreter a virtual environment will be based on"
I know it's verbose and long to type but looks explicit to me and saved me to use the wrong version of Python several times.
Ah! That makes a lot of sense. If Python 3 is the default, it does make sense 'pip' to be the Python 3 pip. That way 'pip' always refers to the default version.
Unfortunately in the Ubuntu and Mac world 'python' is still Python 2.7 and 'pip' refers to the Python 2 pip. Python 3 is available as 'python3' along with 'pip3'.
This is an interesting story. Python breaks perfectly reasonable code which is surprisingly nothing new for Python. A tool stops working. Users want fix. Author of the tool is unavailable. The tool needs to be forked. A new name needs to be chosen. A new distribution point needs to be established.
All because Python chooses to break existing code.
Can't the software designers of this century choose to provide feature flags (use strict, use VERSION, etc.) to enable new features that break existing code?
There was a nice and popular article/blog post from someone famous about never ever breaking existing code or functionality because users depend on it but I cannot remember the title of that post to search it.
I guess you’re mostly complaining about Python 2->3? That was a long time ago, and Python is hardly the only language to introduce a new, breaking major version.
This is a code analysis tool, quite different from your average library. It broke because Python introduce new reserved keywords (async/await). This is a non-breaking change for almost all libraries/software (and if it IS breaking for you, you probably just have to change variable names or something similar), but code analysis tools are different, they have to be totally up to date with new language features. Lots of languages introduce new reserved keywords decently often (in fact, lots have explicitly added async and await somewhat recently), it tends to break very little, except code analysis tools.
Not that I disagree, but "async" is such a generic and widespread term that I can easily understand why they wouldn't want to choose something else. Have you read the kerfuffle about https://github.com/staltz/prevent-smoosh et al?
> With the release of Python 3.6, it became clear that Pylama was in need of maintenance updates. Python 3.6 warned that async was about to become a reserved keyword in Python 3.7.
I can imagine there must be lot of code bases with async as variable name. For example:
Has any other mainstream programming language like C or Java introduced such reserved keywords in a new release? I guess if C or Java were to do something like this it would cause a lot of hue and cry.
I remember when C++ had to introduce a keyword for automatic type inference they reused the 'auto' keyword instead of introducing a new keyword at the risk of breaking a lot of existing code.
How do other mainstream languages handle a scenario like this where a new keyword is required?
C/C++ compilers support multiple versions of the standards at the same time. You can compile one file with -std=c++98 and another with -std=c++17 and link them together just fine.
Rust is now doing the same thing with editions.
Perl has 'use VERSION', but I'm not very familiar with it, not sure if e.g. new keywords only become available with that statement. The docs say 'use VERSION also lexically enables all features available in the requested version…'
enum, assert was added to Java, but nothing major since then. (var is an invalid class name starting in Java 10, and underscore is a keyword since Java 9)
I just can't stand Celery as a project. It takes ages to stay up to date and I have had a few issues with it which just should not happen for such a large project
One model I'm curious about is https://jazzband.co/, "a collaborative community to share the responsibility of maintaining Python-based projects." Not sure how well that works in practice, but it would be great for something like that to crack the maintainer-burnout problem.