bench get-app hrms command inside the backend container of a fresh installation of ERPNext v16 (amd64/linux).
Can this be ignored? I’m experiencing several other errors while using HRMS in general (such as Timesheet Data Import not working), and I’m wondering if those errors are from improper installation.
These errors are related to building HRMS assets. You can try building the assets manually using the bench build command.
What issue you are facing while importing data?
Anyone facing issues with containers report on frappe/frappe_docker, before reporting read the FAQ
for one more time, here is a link to FAQ Frequently Asked Questions · frappe/frappe_docker Wiki · GitHub
I added a message when anyone does bench exec or bench run
❯ docker run --rm -it frappe/erpnext:v15.45.5 bash
Commands restricted in prodution container, Read FAQ before you proceed: https://frappe.fyi/ctr-faq
frappe@ea591d333db1:~/frappe-bench$
Message says: Commands restricted in prodution container, Read FAQ before you proceed: Frequently Asked Questions · frappe/frappe_docker Wiki · GitHub
the frappe.fyi link redirects to FAQ.
Anyone has any idea how to make the FAQ readable?
Challenge is, I know even EULA screens are skipped, why will anyone read FAQ!
Dear Revant, Thank you for this change which might indeed help, a very good idea for CLI users in containers.
You are asking a noble question:
You know, the other day you hinted me over to the frappe_docker FAQ regarding the known SocketIO problem, after I did (and forumed) some hours of debugging.
So I asked myself the same question: “Why did I miss this FAQ entry? Am I stupid or what? What else would be needed to make me find it?”, especially because I spent lots of time reading lots of documentation about docker, configuration, use cases (forum), code, etc., but still the FAQ entry didn’t occur to me. Generally speaking, I rarely ask anyone before trying hard to solve stuff myself. I’m as flabberghasted, about myself, as you are regarding the users.
So there are several points that occured to me.
1 - The DevOps machinery is complex: bench and it’s many commands (not always well documented), Docker (well document, but quite copiously so), and Kubernetes even more so.
2 - You can read all this, but it’s a real lot to learn, and it’s kind of abstract until you hit your personal error case.
3 - Lots of hands-on training would be needed, but this can be expensive (if in time “only”). Even then, building all kinds of complex use cases for training might not exhaust the lack of deeper knowledge which is normal at the beginning.
4 - Graphical overviews might help. There are some “architecture” graphs here and there, but (a) some seem too simple to be more than some eye candy for nicer looking docs, (b) the tools change faster than the docs, so the docs are not reliable and may be out of sync (there is a reason why FC tells the commit hash of apps instead of the version only: the FC team is aware that it needs better info than version tags or branches, which even seem to be conflated in the machinery (but how so?), to get errors solved quicker), (c) the combination of apps complicates things further, and (d) you still need to be able to link your use case to the docs.
The last point (d) is why I’d like to point out this, too:
I noticed that my own errors and bugs generally are intimately linked to some kind of perception bias of myself. These are fine links, even metaphysical mechanics, but strong ones. That’s something I recommend everyone to explore, because it helps you grow. So, as for me, I take this kind of link as a given, and it has an important consequence which I observed many times:
The perception bias (or “blindness”, if you will, for some aspect of life, which can be litterally anything you do to/with yourself and/or others) which makes you commit the error also makes you blind for the solution.
So with all the stuff read and heard, there can be a moment of black-out which just makes it harder to realize what is actually happening.
Generally what helps is thinking hard about what is going on, opening up, reading more, relaxing a bit, asking for help, until you get through the fog, inner as well as outer fog, that is. We are all humans, and fallible, but also self-perfectible, that’s just how it is for all humans.
Once you got through the fog, things look simple and easy. So it’s good to do one’s personal post-event analysis, radically and without any self-flattery, looking at yourself why this happened.
You can also do this as the one who offers the software and it’s documentation (as your questions shows).
Of course, some stuff is lies and fog and confusion hitting you/us from outside (outdated docs, missing explanations, common misunderstandings, cultural differences, different life situations, resources, etc.). Nobody and nothing is really generally responsible, because everybody can err, and of course we get further, and faster, as a team, taken into account all the different constraints which exist in life.
Thank you for redirecting me to the right direction.
I’m not entirely familiar with the build process, so I’m still stuck having tried to follow the FAQ and the official document for installing custom apps.
