parsergenerator.build fails on a read-only filesystem about rply HOT 21 CLOSED

Whoops, accidentally commited directly to master instead of sending a PR: 2a3f626

Feedback welcome

from rply.

Why not use the new fix, instead of a workaround?

from rply.

Is there a stacktrace for exactly what lines are triggering this error?

from rply.

@alex yes: hylang/hy#1598 (comment)

from rply.

Whoops, missed that it wasn't unfurled by default.

If someone wants to write a patch to catch OSError and check if e.errno == errno.EROFS I'd accept that patch.

from rply.

Actually, I'll write it myself, since I want to refactor something.

from rply.

As well, I would be inclined to add an argument to builds to disable the cache in case it isn't desired in the first place.

from rply.

You can pass cache_id=None to the constructor to disable it.

from rply.

You can pass cache_id=None to the constructor to disable it.

Oh, I missed that, thanks.

Feedback welcome

Shouldn't the calls to tempfile.NamedTemporaryFile and os.rename be guarded, too?

from rply.

In case the directory exists, but is on a read-only file system?

My inclination is that if you have an rply directory in your user cache dir, but now that's on a read-only-fs, it's probably a bug and I'd rather be noise.

from rply.

I'm not sure what the exact scenario would be, but IO carries inherent risk (race conditions etc.) and this isn't an essential operation (if cache writing fails, everything else about rply can still work), so I would catch all IO and OS errors here, perhaps with a warning. Similarly, it probably isn't enough to catch only errno.EROFS for directory creation. I don't think AWS Lambda raises that errno, for example.

from rply.

Is there any way I could bypass this problem, even if it's not the best solution?

from rply.

@alex Could you make a new release of rply soon so we can get this fix into the next release of Hy?

from rply.

from rply.

Sure, I doubt Hy will release before mid-June.

from rply.

from rply.

Actually, I've made a Hy PR to disable the cache (hylang/hy#1615) because it doesn't seem to give a noticeable performance boost, anyway. So, this should be a non-issue.

from rply.

from rply.

I bet that Lisp is a lot easier to parse than Ruby. :)

from rply.

from rply.

I did a release

from rply.