Today I tried to install another instance of the last v10 version using the same process I have been using since v11 was released (the easy install script). After it was successfully installed I tried to log into it to complete the setup wizard and I got the following error:
(This is new BTW. Everything worked a few weeks ago)
IOError: [Errno 2] No such file or directory: u’./assets/erpnext/js/setup_wizard.js’
Does anyone have any idea how I can get the setup_wizard.js and put it the right location on this server so I can complete the setup?
Also, If I can get it, where exactly does it go? (need whole path)
Just in case you were trying to read the error in the box, it looks like this:
Traceback (most recent call last):
File "/home/erp_jmi/frappe-bench/apps/frappe/frappe/app.py", line 62, in application
response = frappe.handler.handle()
File "/home/erp_jmi/frappe-bench/apps/frappe/frappe/handler.py", line 22, in handle
data = execute_cmd(cmd)
File "/home/erp_jmi/frappe-bench/apps/frappe/frappe/handler.py", line 53, in execute_cmd
return frappe.call(method, **frappe.form_dict)
File "/home/erp_jmi/frappe-bench/apps/frappe/frappe/__init__.py", line 939, in call
return fn(*args, **newargs)
File "/home/erp_jmi/frappe-bench/apps/frappe/frappe/client.py", line 300, in get_js
with open(contentpath, "r") as srcfile:
IOError: [Errno 2] No such file or directory: u'./assets/erpnext/js/setup_wizard.js
Okay, so I did a search of the installation and found that setup_wizard.js actually exists in 3 different locations in the installation. It turns out to be the same 3 locations on all of my other installations as well.
So, this tells me that the process that calls the setup_wizard.js is likely somehow looking for it in the wrong place?!?
Where can I edit a file to tell the initialization of the first Administrator login to the system to look for the file in one of the 3 current locations instead of wherever it is pointing now?
put import ipdb; ipdb.set_trace() here in the code
Delete the previously compiled code
frappe@ubuntu:~/frappe-bench$ rm apps/frappe/frappe/client.pyc
rerun the setup_wizard with bench reinstall
On the browser client I followed the /desk/set-wizard/0 Hello prompts and so on and Setup Complete ran as expected.
But too bad contrary to expected no debugger session occurred?
Nonetheless this was recompiled (as expected)
frappe@ubuntu:~/frappe-bench$ ls -al apps/frappe/frappe/client.pyc
-rw-rw-r-- 1 frappe frappe 13667 May 27 15:54 apps/frappe/frappe/client.pyc
My goal was to step through the get_js function in client.py to learn about and spot what may be amiss.
This I think is the client side call to the server
Parts of the setup_wizard code run on (the web browser) client and on the server too, to grok the whole picture here is a challenge.
Yes just run bench reinstall no additional options or arguments BKM -
My test case here is a single site, if your case is not but instead multi-tenant, you will need to determine if say --site site1.local or similar will work.
You can skip 1) and 2) with these I wanted to start up a debug session but this did not work for me.
Options:
–admin-password TEXT Administrator Password for reinstalled site
–mariadb-root-username TEXT Root username for MariaDB
–mariadb-root-password TEXT Root password for MariaDB
–yes Pass --yes to skip confirmation
–help Show this message and exit.
As per your suggestion, I skipped steps 1 & 2 since I am not going to try to re-run your failed attempt at debugging. I just ran the bench reinstall command and tried again to login as administrator to finish the setup_wizard but again I get the exact same error as before as if the setup_wizard.js file is not where it is expected to be.
Still hoping someone has another idea to get past this.
Yeah… that is what I thought as well. I just have no idea how to get that part fixed. The corruption seems to happen with all new install of v10 using the easy install script (install.py) from this instruction:
I have not found any instructions for manually installing the last valid v10 version or I would try that as well.
It is really kind of disappointing to find that what was supposed to be a ‘supported’ version is being broken every few weeks by the developers as they make changes in the install.py and the playbook. Nobody ever seems to test this backwards to make sure it doesn’t break the ‘supposedly’ supported versions.
Hopefully someone can suggest another workaround. Otherwise the ‘officially supported’ v10 is actually dead since it cannot be re-installed and configured any longer.
Well, it turns out that the ‘items’ list being invalid ripples through other parts of the system as well.
To try to get around the original issues, I installed the v10.xx and logged in as Administrator to both prove that I could login with success and still get the error preventing me from completing the configuration.
I then restored a valid database from another 10.xx site that I had installed only 24 days earlier and I was able to login to the new installation with the restored data in place and thus bypass the setup_wizard.js problem.
However, as soon as you begin to do anything like edit an inventory item, you will notice similar errors indication another [any-file].js does not exist and you are prevented from doing anything further.
So @clarkej I do believe the items list you speak of is likely the culprit and that it has much more influence on the functioning of a stable system than just getting past the setup_wizard.js
There are several modules that will error thus making the version 10 of erpnext not only dead, but only the beginning of a completely useless ERP project for new users.
For example:
v10 is can no longer be installed and started as a fresh system due to the errors from the topic of this thread.
v11 is suffering from multiple permissions issues and is also unusable from a POS perspective due to the long reported and unresolved issue of problems handling items with variants. This keeps it from ever being useful to a wide range of businesses like retail clothing stores, or any other business that sells items with variants.
v12 is of course only beta and requires a great deal of knowledge to roll the dice with it to try to run it as a production server.
So… Where are the new adopters supposed to go to get a viable ERPNext?
In the beginning of the v11 release, v10 was stable and working, but somehow it keeps getting broken every few weeks. That doesn’t really make any sense. If it was working, then why add anything to it at all that might break it? Or why add anything to it and not validate that you can still install it and use it?
I wonder if part of the problem is that although 10 is still supported at the security and code base level, it’s stability depends on a static requirements versions. As the underlying requirements get updated through upgrades at the OS level, non current ERPNext versions fall out of sync, so to speak, with the programs and libraries it uses- Mariadb, Nginx , Nodejs etc. Might being able to pin those at the versions that were extant at the time 10 was last released help? Is containerization/virtualization something that will make the stable versions available prepackaged with the working requirements?
Probably yes. There are other threads that discuss that very tactic, but it conflicts with the way the dev team wants to run the project.
That would also be a yes, except that what you can do with the containerized versions is somewhat limited. It requires a bit more knowledge about how to manipulate the container construction in order to set one up the way you want it before you deploy it. Once it is built, you cannot change it or add modules easily.
While the container idea is not impossible, it means learning about how to build the container to fit your particular needs. Not every ERPNext container is equal. There is one version out there that lumps everything into one, and others that break out the database into a separate container along with other functions.
The container I would want to use is a bit of a hybrid, so I would have to spend a lot of time in the learning curve first, and then find an functioning install set as the base version to build the container.
