Is there any way to prevent raco pkg from installing a package? Like, (pre-)install-collection for an info.rkt files, but can also fail.

The best I can think of is to have my package’s (pre)-install-collection function throw an error. But the collection will still end up installed, even after the error is thrown.

There’s a way to turn off raco setup when installing, is that close to what you want?

@notjack Can I do it programatically from within a package?

Like, I made package A. But package A requires some system dependency not provided.

I have code that can check to see if the dependency is met, but if it isn’t met, I can’t really fix it.

As such, I just want to bail, and don’t install the package.

(Rather than letting raco finish installing a broken package.)

Ah yeah, no idea how to do that

That seems like a reasonable thing to want to do though

Sad day. Well if it’s not possible, I’ll see if its possible to add it.

@leif That doesn’t sound like a good idea. There can be all sorts of reasons to install a package that can’t currently run, including installing to build documentation or a distribution. It’s much better to have the library report a run-time error for unavailable functionality.

@mflatt Ya, that makes sense, except for when the dep you need is specifically for building. Although I guess in that case an error is just fine.

Thanks. :slightly_smiling_face:

@greg seems back up/fixed

I’m trying to clean up my package status… it is listing as having test errors. If I run tests in racket-mode, I get zero output. If I run with raco test I get:

% raco test --process -t main.rkt
raco test: (submod "main.rkt" test)
3 14 main.rkt
3/14 test failures

which is entirely not helpful… the package status shows an error, but why am I not getting output with either method? Am I forgetting a flag?

@zenspider These? http://pkg-build.racket-lang.org/server/built/test-fail/check-sexp-equal.txt

yes… I’m starting to think that we’re running different things tho… I also have NO IDEA why raco test thinks I have 14 tests

If I add a (displayln 'done) at the end of my test module, it prints and then I get the “test failures” line… I have no idea what’s running at this point

@zenspider which package are you looking at?

fwiw, the “_n_ test failures” line is printed by raco test

I did test coverage in drracket and I only have 2 expressions not covered… and exception and a failure case

but I only have 3 calls to check-exn-info?

https://github.com/zenspider/check-sexp-equal/blob/master/main.rkt

nope… the sha’s match… we’re running the same thing

@zenspider Is that the source?

yup!

it’s probably all the different calls to check-equal? in loops that adds up to 14

and I only have that displayln diff locally

one of the big flaws of rackunit, imo, is that there is basically no possibility for reuse: you generally cannot define a check in terms of another one without things leaking through

haha

@lexi.lambda agreed. I do a number of define-simple-check or whatever it is… but I don’t pay much attention to the numbers… but in this case, since I’m testing a test function… I’m a bit confused.

still… I don’t know how to reproduce the error that the pkg system is reporting

@notjack ^^^ composable assertions would be really really useful

@samth by my reasoning, the number should be 7, not 14

it’s also running my scribble file? I’m not doing that…

the pkg build server runs all your files

does anyone know what the flags are?

see http://pkg-build.racket-lang.org/about.html

--drdr did it! thanks

--drdr Configure defaults to imitate DrDr… wtf does that mean?

drdr is the Racket CI server http://drdr.racket-lang.org

wait. no. oops… that didn’t do it. that was the stderr output from the scribble doco checker I stole from somewhere

what command are you running?

@samth looks like the internal links on that page are broken. Try “Dealing with Test Failures”… should I file a bug?

@lexi.lambda raco test --drdr info.rkt main.rkt check-sexp-equal.scrbl

try raco test --drdr -p check-sexp-equal

hrm:

% raco test --drdr -p check-sexp-equal
raco test: 0 "/Users/ryan/Library/Racket/6.9/pkgs/../../../../Work/git/zenspider/check-sexp-equal/check-sexp-equal.scrbl"
raco test: 1 "/Users/ryan/Library/Racket/6.9/pkgs/../../../../Work/git/zenspider/check-sexp-equal/info.rkt"
raco test: 2 (submod "/Users/ryan/Library/Racket/6.9/pkgs/../../../../Work/git/zenspider/check-sexp-equal/main.rkt" test)
   0 /Users/ryan/Library/Racket/6.9/pkgs/../../../../Work/git/zenspider/check-sexp-equal/check-sexp-equal.scrbl
   0 /Users/ryan/Library/Racket/6.9/pkgs/../../../../Work/git/zenspider/check-sexp-equal/info.rkt
3 14 /Users/ryan/Library/Racket/6.9/pkgs/../../../../Work/git/zenspider/check-sexp-equal/main.rkt
3/14 test failures

I don’t want to port minitest to racket… but I’m close. :stuck_out_tongue:

just some name attributes that should be id attributes — I’ll fix it

I think raco test is okay… it’s mostly agnostic to testing lib. rackunit is eh.

so it COULD work with another testing library? good to know…

raco test just runs your files, basically

can you expand on what you’re “eh” about?

not atm, I’m in a meeting :p

heh. kk. later

but if you’re interested in writing another framework, you can report test results to raco test with test-log! http://docs.racket-lang.org/rackunit/Testing_Utilities.html#%28def._%28%28lib._rackunit%2Flog..rkt%29._test-log%21%29%29

@zenspider that’s now fixed

it’s documented in the rackunit manual but it’s actually not in the rackunit package

@samth cool! thanks!

although that page won’t be fixed until 6.11

sure

but they’re just internal links so it’s not so bad

“Adds a test result to the running log. If result is false, then the test is considered a failure.” … that’s… pretty opaque

it basically just means call (test-log! #t) if the test passes and (test-log! #f) if it fails

raco test uses those calls to display the “n/m test failures” message

OK. so I’m still responsible for my own failure/error reporting… gotcha

grr… I need to STOP thinking about porting minitest. no no no … I don’t need another project

looks like i should poke at current-check-around to make inner failures opaque to the test runner

heh. I DO use that already… so no…

ok…. so check-log! is called inside of functions like fail-check and the like… THEN they raise exceptions for things like current-check-around to deal with… which doesn’t make much sense to me. I should be allowed to use parameterize to completely override how a test gets run/accounted-for.

that sounds like probably the wrong thing, yes

I imagine you could submit a PR to fix that and it would be accepted

it’s a bit of a tangle… I need to wrap my head around it but at least I have a simple test case to reproduce it

or … parameterize test-log! ?

that seems easier for sure… but… maybe less correct?

@notjack ^^^ opinions?

@zenspider oh jeez I missed all of this conversation and it’s so useful. Will respond when back at desk

@zenspider re composable assertions: yes! those would be very useful. so useful, that I’ve been working on a package that provides them: http://docs.racket-lang.org/expect/

they’re not yet ready for prime time, but if you’d like to help it’d be very appreciated. the github repo has a lot of open issues documenting stuff I plan to add: https://github.com/jackfirth/racket-expect/issues

as for the test-log! weirdness: yes, ideally, test-log! would only occur in current-check-around. That’s something I’d like to fix in rackunit but it might break things in strange places. I’m particularly concerned about how that interacts with the test-case / test-suite macros, since they parameterize current-check-around. Personally I think that in a test case or suite the entire case or suite should count as a single test.

oh, and I’ve been looking at minitest’s features for inspiration on perf testing too so thanks :)

@zenspider https://github.com/racket/rackunit/issues/70

saw that! cool thanks!

@notjack what’s your opinion on parameterizing test-log! ?

@zenspider it’s provided as a simple low-level workaround to unblock people who need to extend rackunit or reflect over checks without all their legacy weirdness breaking them

so if it works feel no shame in using it, but if there’s no other option that’s probably because something isn’t designed well and a bug to fix that would be welcome

??? I’m not tracking… are you saying it already IS parameterized?

oh! yeah I added a parameter to disable the log in the most recent racket release

test-log-enabled?

http://docs.racket-lang.org/rackunit/Testing_Utilities.html?q=test-log!#%28def._%28%28lib._rackunit%2Flog..rkt%29._test-log-enabled~3f%29%29

oh shit… I missed the last release. :stuck_out_tongue:

this should fix me right up then…

glad to help :)

Are #:transparent structs supposed to be allowed as place messages? The docs for places in general say “To a first approximation, place channels support only immutable, transparent values as messages” but the docs for place-message-allowed? say “pairs, lists, vectors, and immutable prefab structures containing message-allowed values, where a mutable vector is automatically replaced by an immutable vector” are allowed and make no mention of transparent structures. Attempting to send a transparent struct raises an error.

My guess is that the meaning of “transparent” there is not intended to mean “transparent structure”, but I think the wording could be improved.

@notjack #:transparent structs are not meant to be allowed as place messages

ah, a doc improvement would be welcome then

@notjack are there differences in the failure message output in the new release?

@zenspider slight differences, yes

why do you ask?

I have new failures in my test suite… just making sure. I’d rather update my expected to match the latest version rather than trying to find some way to normalize it at this point

@zenspider you might be interested in https://github.com/racket/rackunit/pull/59 which attempts to add some helpers for testing custom checks without everything breaking every time the message format changes slightly

cool. thanks

that’s slated for 6.11 I assume?

ya, although I haven’t gotten around to resolving the API issues yet

@notjack is pretty-info (or accessors) exported? seems like not

I’m failing because (pretty-info x) vs x

It’s not. pretty-info, verbose-info and location-info were created when refactoring some internal rackunit code implementing run-tests. If you need them (or your test is failing because you’re calling check-equal? on the info struct) they can be exported.

you could also use make-check-expected / make-check-actual, since those add pretty-info under the hood

I just required rackunit/private/check-info and am back on track

that works, although I think using make-check-expected or make-check-actual might also work without you needing to require any private modules

one thing at a time :slightly_smiling_face:

@notjack hrm… maybe I’ll need to do that sooner rather than later:

(exn-message (with-handlers ([exn:test:check? identity])
               (parameterize ([current-check-around (λ (f) (f))])
                 (check-equal? 1 2 "a message"))))

@zenspider do what?

hrm… actually I’m confused by 2 things… 1) the above snippet doesn’t result in "a message"

2) make-check-expected and make-check-actual wrap up in structs that can’t be compared

(check-equal? (make-check-expected 42) (make-check-actual 42))

totally open to changing my code around to fit a better strategy…

The message you pass to a check is stored as a check info with key 'message unfortunately, it doesn’t control the message of the exception directly

(personally I think the message argument just shouldn’t be used)

hrm… ok. It used to be “Check failure” ? … those are two different messages tho?

Yeah there’s two. The default message used to be “check failure” but now it’s nothing. Unless the check passes a string to fail-check there won’t be a message on its own line. The message argument at check use sites always added an info, it’s unrelated to the “Check failure” line

yeah. I was testing that because my previous version relayed everything via fail-check

and now uses check-info

fail-check is the preferred way for a textual message for the user, info is best for structured values

well… this is both :slightly_smiling_face:

ok. I think I have things fixed in a way I like…

do I need to bump the package system or will it pick it up automatically?

I don’t think you need to bump it, the catalog points to your git head and the build server will build the latest every night

I updated the description anyways…. maybe that’ll trigger something

and apparently I never released benchmark-ips… I should get on that

https://pkgd.racket-lang.org/pkgn/package/benchmark-ips

I love this package… use it all the time to compare approaches