Closed yfzhe closed 4 years ago
Quick answer is I'm not sure what's going on. I'm not really maintaining this project anymore beyond bug fixes. I'm not sure if this is a bug, or, an "off-label usage" of Frog? :smile: But if you're wiling to help find an answer and/or make a PR, I'm willing to try to follow-up (probably can't during the last week of December, but before or after).
The code is trying to display a version already specified in info.rkt
, to avoid copypasta and duplication. I would guess that the define-runtime-path
would guarantee that ../../info.rkt
must exist even in a pre-built package... but apparently not? If there is another, better way to do this, I'm happy to use it.
I don't use the pre-built package catalog and don't know anything about it beyond the concept. It looks like @jackfirth does, from using it in racket-docker. Maybe ~if you open an issue there, linking to this,~ he'll know an idea or two?
EDIT: I noticed you hadn't opened an issue there, yet, so I went ahead and did so.
I haven't used Frog so I'm lacking context, but I think what's happening is that when using the built-package catalog, the info.rkt
module is only available in its compiled representation. The compiled representation is what's left after all reader transformations and macro expansions are done, so the file won't start with #lang info
anymore. To get the version out of the compiled info, you'll have to actually require the info module. I see there's a comment saying the current parsing is a workaround for Racket 6 - is supporting that version still necessary?
Thanks for the idea about what's going on!
Frog still supports Racket 6.2 onward. With Racket pkgs/apps generally, I don't like to drop support for older versions unless/until it's absolutely unavoidable. Instead I explicitly run CI against older versions. At one point Frog dropped support for Racket 6.0 and 6.1, and I didn't like doing that, but couldn't avoid it IIRC.
What I could experiment with is trying more of my typical tactics for this kind of thing:
Some use of dynamic-require
to do function availability checks -- not version number checks -- with some "copypasta backfill" (or more-helpful error message) to handle when not available.
When that doesn't suffice (probably as in this case), some use of submodules and/or eval
to discover when the version of Racket has the undesired behavior, and to use another method. Example from Racket Mode.
I'll experiment with this but might not have time for a week or two.
I pushed a commit which I think is sufficient to close this.
I'm not familiar with the prebuilt package catalog, I'm not sure how frequently it rebuilds and would get this change. I imagine you might need to wait as long as 24 hours before you could try again, @yfzhe ?
Or maybe @jackfirth knows some way to use racket-docker
but tell it to avoid the prebuilt package catalog completely (I don't know if that's an option).
You can explicitly prevent usage of the built-package catalog using the --catalog
option of raco pkg install
.
@greghendershott Thanks for your commit! I have not tried it, but I will soon.
I had another solution: make the regexp support the pre-built version info.rkt as we exactly know how it would be. But in a ci environment, the version infomation is little important, so I think just a warning message is ok.
Thanks for your work again, from a daily user of racket-mode and frog (not daily).
Background: I am trying to use circle-ci and racket-docker to deploy my frog-based blog. Racket-docker seems to download the "pre-compiled" package from the package server:
When I run
raco frog --build
, it failed, with the following error message:In the line 181 of frog/private/main, it use regexp
^#lang info\n+\\(define version \"([^\"]+)\"
to match the version number. But the error message indicates the info.rkt is expended, it is(module info setup/infotab ....)
not#lang info ...