ERPNext + Python 3

This should be fixed with

@achillesrasquinha, is it production ready? thanks

1 Like

@achillesrasquinha, is ERPNext with python 3 really not production ready or is it just the python 2 to python 3 migration which is not ready ?
I’m asking because I plan to setup a new “production” ERPNext instance and I would prefer to go directly to python 3 instead of going through the hassle of later migrating…

We’ve been using python3.7 with ERPNext for 4 months now on our production with thousands of transactions per day. Runs as smooth as butter.


Successfully migrated to Python 3 with no issues using these three lines:

sudo apt-get install python3-dev
bench migrate-env python3
bench update


Thanks for your suggestion, it works on production VM.

Now it works with python3

Installed Apps
ERPNext: v11.1.39 (master)

Frappe Framework: v11.1.36 (master)

1 Like

I got updating …msg when i accessed the site. So for me below steps worked

sudo apt-get install python3-dev
bench migrate-env python3
bench restart
bench update

1 Like

May be it is for development not for production (master). Is the reason you restart bench?

Just migrated to Python3.6 (on ERPNext v12.1.1). Getting an SMTP data error when sending out emails with PDF attachments (smtplib.SMTPDataError: (501, b’Syntax error - line too long’)).

Just wanted to know if you have tested for sending out emails with pdf attachments (of sales order etc) and do not face any issues? Will appreciate clarification as our server on python3 is unable to send emails with pdf attachments of sales orders, invoices, etc. Works fine on Python2.7.

No errorsin log here in a Ubuntu Bionic VM. PDF format not right yet though.

ERPNext: v12.1.1 (version-12)
Frappe Framework: v12.0.11 (version-12)

In [3]: print (sys.version)
3.6.8 (default, Jan 14 2019, 11:02:34)
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]]

Thank you for sharing the log. Assuming your comment that PDF format is not right - could potentially be causing this issue?

Also not sure how to interpret the log. Does it show a print test (which btw is working for us on python3) or an SMTP test email with PDF attached?

As mentioned above, PDF generation and visual format seem to work fine. We are getting an SMTP error when we send PDF by email. online search of error suggests that error is related to having a data string in email / PDF > 998 chars which is being rejected by the SMTP server.

Did you mean same when you said PDF format is not right?

I don’t think the PDF format problem, since resolved,is causing your problem, In my case it has due to not having the hostname set to the ip of the host in site_config.json.

Can anyone confirm that V12+Python3 is able to send email with pdf attachment?

I can confim this.

With configuration posted above, it works for Purchase Orders.

I just successfully migrated to Python3.7 and tried to email purchase invoice (with pdf print) - getting the following error:

(501, b’Syntax error - line too long’)
Traceback (most recent call last):
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 406, in send_one
smtpserver.sess.sendmail(email.sender, recipient.recipient, encode(message))
File “/usr/lib/python3.7/”, line 888, in sendmail
raise SMTPDataError(code, resp)
smtplib.SMTPDataError: (501, b’Syntax error - line too long’)

Get error for PDF with / without letterhead. Any suggestions on how to resolve?

Is it a customized Purchase Invoice or the Standard?

Do other forms, Purchase Order or Sales Invoice for example, have same issue?

Have you tried a different email sender account? Could the sender signature have excessive line length?

Hey @smino - thanks for the follow up. Does your email actually go out via your smtp provider and you receive it externally with proper pdf attachment? Will appreciate it if you can confirm.

Email works for us - except when pdf is attached. So it seems not related to login authentication or other email id, etc. When I search for this smtplib error online - it refers to the email_body having a string which is >998 chars (so the pdf is not getting formatted / attached correctly in our case)

I was poking through the code and came across this in (:~/frappe-bench/apps/frappe/frappe/email/ There seem to be 2 separate functions add_attachment and add_pdf_attachment (which calls get_pdf). add_attachment does not refer to or call add_pdf_attachment - which I think it should if the content type is pdf.

This add_pdf_attachment function seems never called by anything??? Instead what is being called in is just the add_attachment. I have half knowledge - so please excuse if I am missing something…

So I am wondering is this is a bug? Thats why I am asking if you are actually receiving the email with proper pdf attachment…Strangely reverting back to Python2.7 (restoring snapshot of container) resolves the issue with same

Email is sent via smtp server (in this case, my ISP’s). TLS enabled. I am sending them to a mail address, opening the email in Firefox and it renders in preview and in Okular if downloaded.

FWIW , this ERPNext started out as a Virtualbox Ubuntu 16 ERPNext 11 ova, the OS was upgraded to Bionic and the ERPNext to python 3. Then upgraded to 12 , then restored data. There were some intermediate steps with mariadb and node repos , and a bit of thrashing about wiith bench update switch-to-version, migrate etc but it has stabilized, it seems.

I just created a container with fresh install of ERPNext - pure python 3.6 - even using supervisor 4.0.4 (have to pip install it) and ensured all other steps per github guide for manual install. Supervisor 3.3.1 as installed using apt-get install method requires python2.7 - so you might have both versions of python installed.

Still get smtplib.SMTPDataError: (501, b’Syntax error - line too long’) when trying to send email with pdf attachment. - has a function on line 163

def add_pdf_attachment(self, name, html, options=None):
    		self.add_attachment(name, get_pdf(html, options), 'application/octet-stream') 

Does anybody know when / where this function is called? I cannot seem to find a reference to it elsewhere.