Hi @Nagaria Hussain
I tried doppio bot in my frappe app. I installed successfully i have redis error.
``
{
"exception": "redis.exceptions.ConnectionError: Error 111 connecting to localhost:6379. Connection refused."
}
For my frappe app /etc/redis/redis.conf
it's running in port 11000
# port 6379
port 11000
How to solve the error
Thank youAnd also while installing i got some error
While installing chat open ai
ERROR: pip’s dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
frappe 15.0.0.dev0 requires tenacity~=8.0.1, but you have tenacity 8.2.2 which is incompatible.
Warn:
react-markdown@8.0.6" has unmet peer dependency “@types/react@>=16”.
This is fixed in a new release: Release v1.0.1 · NagariaHussain/doppio_bot · GitHub
Will fetch from Conf automatically now.
Did you get this while running get-app? BTW you can try installing Python requirements again by running
bench setup requirements
This is just warning, you can ignore this.
okay thankyou sir. It’s working now. Had you written any blog regarding react using in frappe. I want to learn how to use react in frappe. I tried frappe-react-sdk i installed but i don’t know how to use.
Whether npx create-react-app to be done or using frappe-react-sdk in our existing frappe app. If any blogs or tutorial available kindly share it sir.
Thank you
Is it really a good idea to train users (or developers) to ignore warnings?
Aren’t they there for a purpose?
Too often I find them opaque, which creates uneasiness in using a software.
Who would like to use a boat or a plane knowing there are still leaks, used cogwheels with blinking maintenance warnings, unfinished repair works, unchecked QC list items, lost vices in the mechanics and whatnot?
Honestly, it depends. This particular case (yarn/npm warnings during dev in general IMO) it is fine to ignore. I won’t recommend ignoring in Production systems.
Many times it comes with experience on what you can ignore and what not to 
In an ideal world of software, I too feel it should be magical!
Perfection is hard to reach indeed. I agree that building good software is a lot of effort, and often an collective effort, particularly so in FOSS. So it’s never a question of waiting for some magic to “work”, but of the love and work of us.
So log, error and warning messages become the basis of uneasiness, rejections, forum posts and issue reports so people can collaborate with each other. Fine with me, I know (or learn) how to dig in deep, that’s my learning and, as a result, contributing.
I remember the sense of calmness I felt when I first ran an OpenBSD system and typed ps or top or so. There was hardly any process (v. 5.3 or so, this changed a bit today, with bigger machines, more cores and the usual demon zoo so typical of today), so clean and tidy it was compared to linux at the time. Also, the reliability of their man pages are legendary and a source of pride for them, resulting from efforts to describe things exactly as they are. Compared to that, running a Linux system is noisy and feels somewhat more messy, many man pages are hardly more than stubs, although there is progress over the years, of course. When run from the command line, many programs become very talkative. So that’s a feature, but also a source of incomprehension sometimes.
When closed sources are leaked, often people are amazed, or indeed appalled, by the “quality” of the code and it’s comments. Products of haste and greed many a time.
All that is kind of fine with me, trying to be a realist, so to speak. It depends on the size of the contributor community, the maturity of the project and the engineers, and the development culture of the teams and/or the individuals, which can be communicated.
As far as I am concerned, when starting to use a new app or software, I try to understand what’s going on and to resolve warnings or errors, but it takes time to understand even where to look. In such a situation, if experience is needed to understand a warning or do a proper triage of “importance or not?”, then it’s opaque almost by definition.
A bad configuration or some other problem, signaled or not, can easily become the difference between catching a ransomware or not, like any of the bugs not yet discovered.
How can anybody “own” the totality of a software stack in production under such conditions?
So there is a mountain of work just about everywhere. And thus, software, developed in a world wide effort, looks like a product of the whole of humanity to me and reflects its state.
I just wonder if sometimes developers putting a little more thought into formulating their messages, into who is the messages’ audience, and into removing them when not needed any more, might help making collaboration and implementation of software in the intended use contexts easier, as might of course users, and devs, learning more about their software, frameworks and configs, from their side of the collective effort.
But well, I agree, the world is what it is, and what we make of it – all of us.
