Does fabric (http://docs.fabfile.org/en/1.7/) support Python 3 yet. As per Python 3 Wall of Superpowers it does not yet.
If not what is the best alternative if using Django 1.5 with Python 3.
Current advice
It seems there is already official support for Python 3.4+ in Fabric v2+ and I guess it should be preferred although there may be some incompatible changes. So in an ideal world, nobody should have this problem anymore :)
pip3 install -U "fabric>2.0"
Maintained old API in Python 3
Because some people were happy with the old API of the Fabric, there is a maintained fork supporting Python 3 called fab-classic. See also discussion in the Github issue Recreating the Fabric 1 API in Fabric 2?
The previous advice
There is Python3 port of Fabric named Fabric3 which supports Python 2.7 and 3.4+ (dropped support for Python <2.7). I use it some time as a replacement and it works for me without any issues.
pip3 install fabric3
Current Answer which has already been done by #miso.belica
pip install -U "fabric>2.0.0"
OLD Answer (as of 2013)
From the docs:
Please note that all documentation is currently written with Python
2.5 users in mind, but with an eye for eventual Python 3.x compatibility
Or to be more specific:
eventual Python 3.x compatibility
It looks like Python3 support for fabric is a little sticky and depends upon another open source library, paramiko being compatible with python3. As of now, the master version supports python 3.
It might be worth messing around with and then building your fabric instance on top of that instead of getting it from pip.
You could also create a separate python2.7 virtualenv just for fabric:
sudo virtualenv --no-site-packages -p /usr/bin/python fabric-env
source /var/www/APPNAME/fabric-env/bin/activate
sudo /var/www/APPNAME/fabric-env/bin/pip install fabric
deactivate
Then:
/var/www/APPNAME/fabric-env/bin/fab -f /var/www/APPNAME/fabfile.py FAB_COMMAND
It seems that Fabric is going through a rewrite and that Fabric 2.0 will be python 3.x compatible. At least this is what I read between the line of the roadmap below. However, I cannot find the Fabric 2.0 repository or branch, so, hard to fully confirm.
http://www.fabfile.org/roadmap.html
For those looking for a supported version of Fabric 1.x, there's a fork which is maintained:
https://github.com/ploxiln/fab-classic
I recommend using it in case you don't want to rewrite all the existing code. And it works with Python 3.7.
We've switched from fabric3==1.14.post1 to fab-classic==1.15.2 without any problems.
It is actually possible to get Fabric to work with Python 3. You can see how I did it in this gist.
In the comments above, #rnevius suggests that invoke is meant as a successor of Fabric 1.x, however that is not completely correct. From the invoke docs:
Thus, Invoke was created to focus exclusively on local and abstract
concerns, leaving Fabric 2.x concerned only with servers and
network commands.
It thus seems that Fabric 2.x will be built on top of invoke. Hopefully, Fabric 2.x will be available soon, so Python2 can die as quickly as possible.
By this day "fabric 2" is awailable to work with python 3+.
"fabric 3" is unofficial fork.
To install "fabric 2" from https://pypi.org/project/Fabric/ :
pip install Fabric
Related
This question already has answers here:
What is a virtualenv, and why should I use one?
(4 answers)
Why is virtualenv necessary?
(5 answers)
Closed 6 months ago.
I'm new to django and i want to know why i need to use a virtual enviroment for django.
You don't, but it's nice to have. If you plan on working on other python projects or having other people work on it, it'll probably be a good idea to have it..
then to set up the project in any pc all you need is:
virtualenv django
workon django
pip install -r requirements.txt
# ^ remember to make a req! it's super nice
# init the db
python manage.py runserver
Super easy!
Note: if you use windows you need the virtualenvwrapper package
The python installed on your system has its set of packages. When you create any python project, as you grow using Python and Django, you will see that it's not necessarily all the packages you wish to use for that project.
A virtual environment would allow you to have a somewhat isolated environment where you can use the Python version you want, the list of packages you want, and install new packages for that environment only.
A time will come when you would be required to list all the packages necessary to run a particular Django project and put these in a "requirements.txt" file using the desired package manager of your choice. A virtual environment would make it easy to track both the packages and their versions.
You can read the Whys here:
https://www.geeksforgeeks.org/python-virtual-environment/
https://stackoverflow.com/questions/39055728/importance-of-virtual-environment-setup-for-django-with-python#:~:text=In%20most%20simple%20way%2C%20a,installed%20in%20the%20host%20machine.
Virtual Environment is generally about control of versions of different libraries used in your project.
When the only computer is used and the only project is coded, you probably won't deal with versions. But imagine that you have two projects on two computers - one on Django 2.3 and another one - on Django 4. Some of third-party packages will require versions of Django not higher or not lower than the exact version. So if you wanted to switch projects between computers, you would have to reinstall all the libraries on your computers according to needed versions and struggle with some conflicts.
installing libraries inside of a virtual environment solves the problem.
We use apache-airflow 1.10.12 for our current system. We need some classes from providers available in airflow 2.*. The airflow docs recommend to use these classes in airflow 1.10 using the backport package. This will allow us to test the new classes without jumping onto airflow 2. But when I install the backport dependency after the core airflow, I get the following error:
"Failed to add packages, reverting the pyproject.toml to its original content" after throwing a bunch of warnings and errors.
Have you faced this before and were you able to resolve it in anyway?
To recreate the steps, here's what I did:
poetry init
poetry env use python3
poetry shell
poetry add apache-airflow="1.10.12"
poetry add apache-airflow-backport-providers-google (this is where tons of errors get thrown with the message mentioned before).
First of all Airflow 1.10.* has reached end-of-life as of June 17th 2021. It's not supported any more by the community and it will not receive any more fixes - not even critical security fixes. In fact there were already security fixes in Airflow 2 that have been fixed but they are not fixed in 1.10 and will never be, so you should upgrade to Airflow 2 as soon as possible otherwise you put your business at risk. You can find out more about it at our discussion panel at Airflow Summit two weeks ago: Keep your Airflow Secure.
Not upgrading to Airflow 2 now is a very bad idea (like any other outdated software), especially taking into account all the ransomware attacks and generally supply-chain attacks.
Secondly, you should not use poetry to install Airflow, not even the latest version. It is not supported. Airflow has complex dependencies and if you want to install airflow in reproducible way, you need to use pip and constraints mechanisms.
Poetry has very opinionated and simplistic view on the dependency resolution and it does not have constraint support and you will not be able to use constraints. In the latest documentation we specifically mention that you are not advised to use poetry to install airflow: https://airflow.apache.org/docs/apache-airflow/stable/installation.html#installation-tools
On the other hand pip has made a terrific progress recently with resolver and general resolution capabilities and avoiding/resolving conflicts.
The official way of installing airflow with 1.10.12 is here. Just follow it:
https://airflow.apache.org/docs/apache-airflow/1.10.12/installation.html
Also it might happen than latest version of backport providers will generate other dependency problems because it stopped being released already more than 6 months ago. In this case you might try:
pip install pip==20.2.4 before you install airflow - you might avoid some conflicts that were resolved after we released 1.10.12 and the backports.
try some of the earlier version of the backport providers by specifying ==<version when you install it. You can see all the versions here: https://pypi.org/project/apache-airflow-backport-providers-google/#history
Also note that backport providers stopped being released more than 6 months ago and there were MANY fixes and improvements in airflow providers google since which makes it even more important to migrate to Airflow 2. The longer you delay the inevitable, the more problems you will have (on top of the aforementioned security problems)
TO install airflow providers google you need airflow 2.1+ apache-airflow-providers-google
Using HLF 1.4 and trying to conform to documentation, however, docs indicate that go 1.11.x MUST be installed -- is there not support for go 1.12.7? If not, when? 1.11.x is considered "archived".
Please advise. Thanks.
I'm currently running fabric 1.4.3 with go version 1.13.5 so it seems that the docs are out of date
I'm trying to work with the Google contacts API using Python 3.5, this presents an issue because the gdata library that is supposed to be used is not up to date for use with Python 3.5. I can use oAuth2 to grab the contact data in JSON and use that in my project, but part of the application is also adding a contact into the users contact list. I cannot find any documentation on this part, besides using the Gdata library, something I cannot do. The majority of project requires Python 3 so, switching to Python 2 would just not be something I could easily do. Is there any further documentation or a work around using the gdata library with Python 3? I'm actually very surprised that the contacts API seems so thinly supported on Python. If anyone has any further information it would be much appreciated.
For me I had to install like pip install git+https://github.com/dvska/gdata-python3 (without the egg). Since the package itself contains src dir. Otherwise import gdata would fail. (python 3.6.5 in virtual env)
GData Py3k version: pip install -e git+https://github.com/dvska/gdata-python3#egg=gdata
I noticed twisted.conch is not part of dist3.py for python 3.Is it not yet migrated to python 3? I dont find any recent updates on the same when i search. I was planning to use it to establish multiple telnet sessions which ll help asses logs in my django app and also help debug live django application using manhole.
IS there an alternate i can use for my use case?
I checked out asyncio. However, my understanding is it might freeze the application during debug which would not suit my need.do correct me if my understanding is wrong..
pls point me to latest twisted package for python 3 with conch support if available . if not, do you have any alternate suggestions?