main.py not executed, but can be imported. #2026
Comments
Why do you think there should be scripts/main.py ? |
|
Oh, that isnt the place for it? I thought that folder was transferred onto the rom (and it is as I can import main) |
|
Yes, scripts/ is system-level thing, useful for advanced users. Novices and end users in general should not change (or add) anything to scripts/. The main.py should be in the filesystem. |
|
Cool, and whats the best way to get main.py onto the filesystem? |
|
The best to find an answer answer to any support question is by joining and reading forum at http://forum.micropython.org/ . You are welcome to use this bug tracker for bug reports. |
|
Obviously this was not intended to be a support question as I opened the bug as it wasn't clear to me where main.py should live. (I still think that if main.py is in scripts it should be executed. But thats just me.) |
|
Sorry, "wasn't clear to me" isn't a bug. It's either lack of studying the topic on your side (or using wrong resources), or an issue on our side of not providing clear/accessible documentation. That's why I asked why do you think there should be scripts/main.py in the first place. |
|
In this case the bug is the error message should be more precise. "could not open file 'main.py' for reading" is ambiguous, it should read "could not open file 'main.py' for reading from the internal filesystem" or something to that effect. |
|
What makes you think it's an "error message"? Maybe it has "error" in it, or colored red? It's a standard diagnostic boot message which any booting device produces bunch (or gazillion) of. |
|
I dunno where the attitude is coming from. I'm simply trying to suggest an improvement that would have avoided the need for me to open this ticket. If the message had have read "could not open file 'main.py' for reading from the internal filesystem" it would have been pretty obvious to me what the problem was, hence I wouldn't have bothered opening the issue. |
|
It's coming from people who seem to come with more or less random (alternatively, severely outdated) presuppositions (e.g. that scripts/main.py should run). When asked where they got that idea, they ignore the question, and instead keep repeating their more or less random presuppositions, ignore hints that there's actually something to learn on their side.
Right, it was the same to me with the cases like #2022 - I took my macbook and went to Apple shop, straight to Genius Bar or how it's called, and told them: "hey, your ar is broken, fix it!" And they replied: "Yes, sir, you're right. But we won't fix it, so learn to deal with it." So I did. P.S. the message is of course generic and not tied to any filesystem and can't be changed on a whim. Clean patches are always welcome though, but it may take some good argumenting that there's actually something to fix. |
|
Given there is no mention in the documentation (https://docs.micropython.org/en/latest/esp8266/) as to where main.py should live, it's pretty reasonable to think that if there are a load of python scripts in the "scripts" directory that main.py would (and probably should) follow the same pattern. Flaming people that are genuinely trying to test and suggest improvements to a project is going to be counter productive in the long run. |
|
Yes, so I'm trying to explain why questions asked in response are important, and why answers to them are useful. The common situation we have as that some random guy wrote in his blog something year ago, and now people come and report "that it doesn't work". And extracting the fact that it's all based on some old "gossip" is quite effortful, as many people come with assumption that they know how it should be, and if that doesn't work for them, something is broken.
Right, and the documentation isn't ready yet, so so far the port is of interest to developers, and all the information is available in git log and tickets here. And from people who're interested in contribution, we really could use clear 8000 and concise reports, not long arguments on who knows better what should be done. |
|
Description of the boot process has been pushed as a22aa53 . It will be on docs.micropython.org tomorrow. Comments/suggestions/articles fixes from native English speaker are welcome. |
|
Hi, I'm reading this conversation 2 years after the fact, but can't help but comment that the attitude from pfalcon was completely uncalled for. I can understand him getting frustrated with having to deal with mundane issues repeatedly, but he didn't have to take it out on dmarkey so harshly. My opinoin. |
Fix missing write_ram_command in _stage
Hi,
cat scripts/main.py
import webrepl
webrepl.start()
But on boot:
could not open file 'main.py' for reading
#5 ets_task(401002d8, 3, 3fff5180, 4)
MicroPython v1.7-257-g26fd0ac-dirty on 2016-05-02; ESP module with ESP8266
Type "help()" for more information.
However I can import main...
The text was updated successfully, but these errors were encountered: