FWIW I found a way to use the legacy authentication: https://tableplus.io/blog/2018/07/failed-to-load-caching-sha2-password-authentication-plugin-solved.html

I think I’ve found a bug in the package server. My new package1 is marked as having conflicts but the link takes me to https://pkg-build.racket-lang.org/(indirect%20conflicts.txt) rather than https://pkg-build.racket-lang.org/conflicts.txt . My package doesn’t show up in the latter so I’m not sure what’s up. Has anyone run into this before?

Ah. https://pkg-build.racket-lang.org/ says there are conflicts in a dependency which now makes sense (because it depends on postmark-client, which does have conflicts and appears in the conflicts.txt file). Nevermind. :smile:

Is there a way to declare that a particular folder within a package should be ignored upon install?

Currently, I have https://github.com/Bogdanp/koyo/tree/master/koyo-lib, which refers to https://github.com/Bogdanp/koyo/tree/master/blueprints at runtime. This works fine for development if I install koyo-lib as a linked package. It doesn’t work when I deploy the package because the location of blueprints is outside of the package’s installation path so I get this error after I install the package:

directory-list: could not open directory
  path: /root/.racket/7.3/pkgs/koyo-lib/koyo/../../blueprints

If I move blueprints inside koyo-lib, then that causes problems as well because blueprints contains racket code (and koyo-lib is declared as a multi-collection package (though I could change it to a single collection package, but I’m not sure that would help)).

So what I would like to do is move blueprints into koyo-lib but somehow tell raco pkg that it should ignore the blueprints folder when koyo-lib is installed.

I have read about the source-omit-files configuration value but I don’t think that’ll do what I want. It sounds like if I add blueprints to source-omit-files, it’ll remove the folder before the package is installed.

Any ideas?

@popa.bogdanp if you want raco setup to avoid trying to compile that subdirectory, I think you want compile-omit-paths. (I didn’t find source-omit-files)

Ah. That sounds promising! Thank you!

source-omit-files is described here: https://docs.racket-lang.org/pkg/strip.html#%28tech._binary._package%29

Also, are all of the #info configuration options listed in an index anywhere?

@ryanc that did the trick. Thanks again!

@carl.morris.world Are you still having trouble? If so, I think the concept of phases might help: basically, a phase either compile-time or run-time. In Racket, though, the compile-time of some code that uses a macro is the run-time of the macro’s implementation. Since macros can (and usually are) written using other macros, we have a more general notion of phases to be able to talk about the compile-time of the compile-time, which is ultimately the run-time of something.

In your example, parse returns a run-time value representing a piece of syntax. On the other hand, record is bound to a macro for use in the implementation of your example. Nothing connects the two pieces.

The normal way to use brag is in the implementation of a custom reader for a new #lang language. The reader implementation would produce the syntax for a Racket module (i.e. (module foo my-new lang "a"). The language implementation would then provide the record implementation for use by programs written in your new language.

Thanks for following up. I settled on a solution based on creating a #lang language with a #%module-begin macro that expands to something like (provide result) (define result ,read-syntax) then in the user module there’s a function that wraps the CSV in make-module-evaluator to get the value of the result variable exported by the module. I think this is similar to what you described.

Phases is definitely the missing concept for me. I just barely understand that macros expand during a different phase compared to when (most) functions evaluate. I think part of the confusion is that I can write macros on the REPL and everything seems to work and then I seemingly get different results compared to a module.

I assume this differences is due to how phases are handled.

Alternatively, I’m considering changing to simply use syntax->datum and treat the result kinda like an xexpr that I iterate through, delaying evaluation using quoting instead of macros.

Your current plan is very reasonable. #lang info does something very similar, as does #lang scribble/manual (for much more complicated values).

Doing syntax->datum and manipulating the raw data could also work. It depends on what your overall goals are. Do you need to accept untrusted input? Do quotable Racket datatypes work well for what you need?

If you go for a syntax->datum-like approach, parser-tools/yacc lets you write actions as normal Racket expressions, so you wouldn’t have to build up an s-expression AST as with brag.

I guess you’re right that syntax->datum might leave you vulnerable to racket code embedded in the CSV data.

I’ll have to take a look at parse-tools/yacc. My initial goal was to simply try expressing a CSV as a parameterized #lang brag parser. However as I worked with it, I had the idea to make an executable CSV.

The idea is to expand the CSV into a racket form (not sure the exact format) which the user provides definitions for (perhaps through parameterizing some procedures/callbacks).

Some of this functionality already exists in the csv-reading module so I may look there next to see if I can implement what I want as a layer on top of that.