Sorry, but I have to correct you here.
Firstly, due to its Darwin inheritance, MacOS X have more code coming from FreeBSD than from OpenBSD. With MacOS X, Apple even synchronized all its BSD layer with FreeBSD 5, to definitively get rid of its patchwork of BSD inheritance. And starting there, they stopped to import BSD code.
God damn it. I always confuse those two. Thank you for the correction. But, anyways, my point is that os file system functions should error messages like EACCESS and ENOTDIR and, thus, should be used and relied upon over, or in addition to, your own error messages.
Secondly, this is assuming that the game dev own a Mac, what is rarely the case. For their vast majority, they just ask Ren'Py to generate the Linux and MacOS distribution, expecting them to be correct ; what happen 99,99% of the time.
True, but the open documentation I'm referring to refers to standard C open().The error reporting and messages should still exist regardless of OS. Especially nowadays where C is pretty standardized even across windows and mac. More so if it's ported to, and ran on, a mac. Just because someone isn't working on a particular OS, doesn't mean they shouldn't consider it. Doubly so if the game dev plans to port to it.
Thirdly, as I said this is not the kind of error that are common with Ren'Py, because they have no reason to happen ; especially at this level.
Common or not, you don't assume. This is the kind of thing that opens up security flaws in programs and games. Always check your inputs lest you incur the wrath of little Bobby tables. (Just in case you've never heard of Little Bobby tables, Search "XKCD little bobby tables". I guess even if you do know it, search for it anyways. It's always good for a laugh.)
If Ren'Py can starts, then the only effective file IO error that can happen is a write access for the log file. In which case the error message is explicit: "IOError: [Errno 30] Read-only file system".
But none of that is true. If Ren'Py can start and then it's importing external libraries, lots can go wrong. This might be the "common" thing, but when you're doing things like loading external resources, you're no longer doing "common" things. Otherwise, this thread wouldn't even be opened. Just because it's an edge case, doesn't mean you don't deal with it.
Even save files wouldn't trigger an error, because Ren'Py double them.
One copy is stored on a directory that will explicitly have the correct rights. This leave only one possibility in terms of IO error, a missing file. But here the possibilities are even more limited. It can only be a game file if the dev haven't tested his game prior to the distribution building, or totally messed his building rules (but 99% of the devs do not change them). What mean that a missing file mostly come from a corrupted archive, and therefore the error message will appear when uncompressing the game.
*Rubs neck nervously.* Yeah... I've crashed Ren'Py games messing with save files before. So I can't say I agree. (Tried to do a binary diff on 2 different save files and applied it to a third. It was my first attempt at cheating in a Ren'py game). But also, consider this, you sym link ~/.renpy to a fat32 partition. No matter what you do, it'll never have the proper permissions. Even chmods will look like it went through fine, but the permissions won't apply. I can probably think of worse things to do, but my initial point was, you don't assume. You write the error message to what it actually happening, not what you think is or will happening.
The case presented in this thread is really particular, because involving a third party library that do not regard Python and have to be partly installed by the game dev.
Yeah, but if there's documentation in Ren'Py's page and the game dev is a beginner, how would they know this is a particular case? We can't say the dev is excused from doing out of the box because it's out of the box, but it's common practice so it's excused that they didn't take extra precautions.
Something that, so far, only happen when the game need the Live2D support.
And, once again, having the error status returned by the OS wouldn't help.
I partially agree with you. The error status from the OS wouldn't have helped, but that's because the true error wasn't from the OS. It was from the load(), but the error message returned was written like it was an OS issue. If it was written correctly, would it helped you solve the problem? Probably not. Would it have prevented you from chasing down a bad lead just because the error message was misleading, thus saving you some time? Definitely. And that's what I'm going for. Messages, particularly error messages shouldn't be misleading simply because someone assumed. I mean, look at the code:
Code:
fn = os.path.join(os.path.dirname(sys.executable), dll)
if os.path.exists(fn):
dll = fn
if not PY2:
dll = dll.encode("utf-8")
if not renpy.gl2.live2dmodel.load(dll): # type: ignore
raise Exception("Could not load Live2D. {} was not found.".format(dll))
Here's all it would have taken to do what I'm advocating for:
Code:
fn = os.path.join(os.path.dirname(sys.executable), dll)
if os.path.exists(fn):
dll = fn
else:
raise Exception("Dynamic library file does not exist. File path: {}".format(dll))
if not PY2:
dll = dll.encode("utf-8")
if not renpy.gl2.live2dmodel.load(dll): # type: ignore
raise Exception("Live2dmodel failed to load dynamic library. Dynamic library file path: {}".format(dll))
And that's all it'd take. I'm not saying whoever wrote this is bad and should be fired or whatever. But it is something simple that can be improved and save people headache and misunderstanding. Like, if I was the mentor or team lead of the programmer that did this, I'd take a sheet of paper, roll it up, bap the person lightly on the head, go "Don't skimp on error messages." and that'd be the end of it (after making sure the person write better error messages, of course). Like, I'm pretty sure I've done something previously when I did lead a team.
The dev provide the Live2D SDK archive, then Ren'Py SDK install the files it will need for the distributions, ensuring that they are put at the right place, and with the correct rights. This mean that ENOTDIR is not a possibility, because the library is stored in the same directory than the Python interpreter. If the directory do not exist, Ren'Py will not starts at all. And it also remove EACCESS as a possibility, unless the game dev voluntarily messed with the rights.
ENOENT is excluded too, due to the impossibility to get a ENOTDIR status and the fact that it's not a creation. Same for ENAMETOOLONG. The only possibility to get it is to reach the 32,767 characters limits for a MacOS path, will this even happen one day ?
ELOOP and EISDIR can't happen due to the way the distribution are built by Ren'Py. And if it was an EINVAL or EPERM error, all Ren'Py games using Live2D would be impacted.
EMFILE is really unlikely to happen, and it apply even more for ENFILE.
As for ENXIO, EINTR, EOPNOTSUPP, EWOULDBLOCK and EBUSY they aren't a possibility here. Same for EROFS, ENOSPC, EDQUOT, ETXTBSY and EEXIST since it's not a creation.
This only leave two possibilities at this level, EIO and ENOENT. And there's near to no software that handle the EIO case as a specific error.
Keep in mind, me saying the system returning those errors is not me saying those should have been reported in this particular case, because that's not the issue. I'm saying that *if* those errors are raised, they should be given to the player and/or the dev. (Or given to the player so the player can report it to the dev). My point is still that a error message should be better than a "check engine" light.
What is missing isn't to handle the access error, but to discriminate between a file error (can't access the file), a system error (the library isn't valid), and a purely software error (the library can not be used with this configuration).
Agreed. This is what I'm trying to convey. By simply having a "Could not load Live2D. {} was not found.", it doesn't discriminate between any of those cases.
If the said database file is provided with the software, installed in the same time than it, and in read only access, it's perfectly legit. It can only be corrupted during the installation, and the error will be handled at that time.
Not true at all. There can be data rot on the physical medium or if the file downloaded missed a few bits in the packet/transmission. (assuming you didn't sum check the download. That's happened to me a few times. The linux installer ran just fine. As if nothing was wrong. But on execution of the OS for the first time, things didn't work.) I've even once had a scenario where the settings of a DSL modem had MTU's set to a number that 1 particular ISP didn't like and every third to seventh file downloaded was corrupted.
Also, you don't install .db files for sqlite. They're just files. You just load them. Not that this changes, adds, or detracts your point in anyway. Just pointing it out. Sqlite is a bit different from all the other sql flavors out there in that the database file are files that you can freely toss around and doesn't need to be in a static location and heavily indexed and all that.
The library do not works, then the dev seen it when it tested his game.
Agreed.
The library have been corrupted when installing the game, and the player learned about it when uncompressing the archive.
Not always the case. See 2 paragraphs up.
The library is purely missing, and the error message is correct.
Agreed.
The library is incompatible, and it's the case missing ; but I'm not sure to what extend MacOS is verbose regarding that issue.
I assume you mean "it's the case here" rather than "it's the case missing". Which, yes, agreed. But, in this case, the loading is done at the application level, at Ren'Py's core, which means Ren'Py should report the error message, not the OS. File missing, permissions denied, all the FS stuff should be at the OS level. Loading libraries should be at the application level so the application should sending a sensible error message.
In the end, I think you and I agree on the same/similar things but in different ways. I don't know anything about you but I'm willing to guess your views are closer to that of a game dev than an application programmer. As such, you're more will to give the benefit of the doubt to, possibly janky dev tools and game libraries and game devs. Even I know how janky and broken some game dev tools can be. Where as I come from a background where, if error messages aren't maintained well and inputs aren't sanitized, other devs five years down the line might waste entire days trying to chasing down a cause to an issue that's not really a cause or someone's machine/server can get hacked and customer data might get stolen. There's waaaay less a concern of that in a game. (well, unless it's an online game, but that's a different conversation.) And honestly, that benefit of the doubt? That's admirable. Game dev is hard. I certainly won't pretend it's not. But, for me, at least, good mental framing and good coding etiquette/discipline goes a long way in preventing a lot of headaches later on.
I just want to say, I know we've gotten waaay off track from the original issue. But I just want to thank you for having a nice chill and informative (at least for me. I don't dive into python stuff often. Cards on the table, I hate python as a language. The only major language I hate more is Ruby.) conversation on tech. I don't get these kind of civil conversations often in English. Doubly so if they're about tech. So, once again, thank you.
