Is it a good idea to ask for a better support of this “package splitting” convention in Rhombus? For instance, all -lib packages are marked “This package needs documentation”, but that’s the point of that package—it shouldn’t have any documentation.
And like, it really pollutes the package server
The link from documentations will mostly point to the -lib package which is usually not the desired one to raco pkg install on. Clicking on -lib package won’t show any link to the root package, etc.
@deactivateduser60718 changes like that sometimes get missed by raco setup . If you had raco pkg remove d and re-installed polyglot-doc , I think the docs would’ve started building again.
The last few times I’ve created new packages, I’ve split two ways instead of four. The -lib package gets the code and the “main” package gets docs, tests, and the dependency on -lib. It’s somewhat easier to maintain and it keeps the benefit of a -lib package with minimal dependencies. It doesn’t eliminate the problems sorawee mentioned wrt the package server, but it reduces them. So I recommend a 2-way split instead of 4, but I’m curious if people have counterarguments.
I recommend not splitting at all and relying on precompilation and the built-package catalog. The splitting just isn’t worth the maintenance cost or the community problems it creates. Splitting pushes you to ask all your dependencies to split, which creates churn and busywork that’s essentially wasted if even a single dependency doesn’t do it.
Plus it means you can’t have test submodules anymore.
Splitting is a mechanical global code transformation. That’s not the kind of thing humans should have to do.
Would it help if making “splitting” into some package system mechanism, in another words, making lib, test, doc components of a package at the aspect of the pkg manager?
They basically are already. The submodule system allows the package manager to tell the difference between library code, tests, and documentation. That’s why things required within a test submodule only need to be added to build-deps instead of deps.
@samth Thanks for data/heap, it’s very useful. In this lib, I have a need for the non-exported heap-get-index and heap-remove-index. Is there a particular reason why they are not exported, or is it due to the lack of good reason at the time?
Ah, wait, maybe I can make do with just heap-remove!
@notjack I’ve never seen a binary package install actually work. I just tried again, and I got the error “package content is not compatible with the requested conversion…”. The command line I used was raco pkg install --binary sql. I also tried the --binary-lib mode instead. I also tried installing rebellion and expect instead. Do any of those work for you? What I am doing wrong?
hm… unfortunately heap-remove! does not return whether the removal was successful, so I’d need either that or access to the aforementioned functions I think.
Anything against returning whether the removal was sucessful?
But there are always some people try doing some “package splitting” things, for dependency, for installing.
Adding those functions and improving the return both sound like good ideas
I don’t know that I wrote that code, but I’d review a pull request to add those things
Agreed. I understand the need to scope dependencies to particular packages, and that makes sense for my case. But I really feel a lot of tension caused by coupling the file system structure to certain usage patterns of Racket modules. Of everything in Racket, this is the one area where I have been repeatedly confounded and in need of guidance on the same questions.
Is there a reason why a single info.rkt file cannot clarify the role of all packages in a project, such that the programmer can organize it how they see fit?
It feels like I’m performing several highly-specific rituals to do the same thing: Tell raco that these modules are intended to do X.
> that makes sense for my case To add color to this: unlike-assets and polyglot are positioned such that they can produce documentation regarding several other packages in the ecosystem, but none of those packages should be a dependency of a -lib package.
Oy. Thank you.
As for package catalog pollution, that has more causes than just splitting.
e.g. uri looks unmaintained at first glance, so if you want to write an alternative implementation you need to eat up a new name and leave people to do more homework on which to use.
what is the difference between racket draw and pict?
@jestarray racket/draw is an imperative drawing library thats more “traditional”. pict is a functional drawing library based on combinators.
pict tends to be a bit higher level and can drop down to the racket/draw level using the dc function, so for most things I tend to prefer pict, but it depends on what you want to do
The problem is that splitting in Racket is very hard. In particular, if you allow dynamic-require then it’s basically impossible to split in a way that is sound.
This question gets asked all the time
But also with respect to the 2htdp/image library
@samth I’m having trouble understanding what you mean. How exactly does dynamic-require complicate things? I understand that it becomes dependent on a name that’s easy to forget about from a maintainance perspective, but that’s all I’m seeing.
Let’s say you want to prune out test submodules. You need to determine that they’re never required from the main body of the code, which is easy, but what if some code path results in a dynamic-require of that submodule? Then pruning it would break the program.
do people use pict for text rendering o-o? i want text to be selectable ;s
What kind of program are you making?
Ah, gotcha. I did encounter a similar problem with the split where I needed require/expose to account for bindings I previously had by virtue of module+. Not the same problem, but the issue you’re talking about makes me feel the same way.
a slideshow program with selectable text :0
I am unsure what the best approach is.
When you said selectable, I thought of “editors”: https://docs.racket-lang.org/gui/editor-overview.html?q=gui
(in particular a pasteboard)
Did you update your package catalog to use the built packages? Also since we are on the transition from 7.5 -> 7.6 has the built server caught up?
I don’t think that’s really all that big a problem. Just give people a way to say “this dependency is used reflectively”. That’s what many other build systems do and it works well in practice.
I don’t think they need to. If you install a package from the built-package catalog and using --binary-lib, you won’t need to install build-deps at all.
It’s not a smooth workflow. But given the choice between spending my time maintaining package splits and spending it improving the built-package workflow, I’d choose the latter every time.
FWIW, right now I can install --binary-lib with rebellion only for 7.5
Same for sql
@ryanc Also make sure you’re using the same variant of racket as the build server. Won’t work if you’re using RacketCS.
And isn’t that essentially the point of define-runtime-module-path-index?
sorawee, with your source code on Racket 7.5 I get: “Failed to load resource: the server responded with a status of 404 (File not found)”
Bogdan, thank you for the tip about looking at the network tab in the browser developer view. Under JS, I see:
What OS are you on? My code definitely should work.
Yes, but in general I think racket’s philosophy is not to break programs that are mis-annotated in that way
Dependency annotations are a very risky place to adopt that philosophy
I wonder if CI on the package build service could play a role here? In some ways it’s analagous to listing your dependencies in an info.rkt file in general, in that the package will work if you have happen to have the environment it needs. But package authors get strong feedback when the mess up their dependencies in the form of failing builds. If there were equivalently smooth processes for testing and using binary-lib packages, I think social processes could go a long way. It seems at least as reasonable to ask someone “please fix this buggy annotation” as “please refactor your one package into four packages.”
It can definitely help. The intersection between large scale CI, code health, and machine-assisted refactoring is a very exciting area.
But then, I haven’t split any of my packages, and I use Scribble on our server to provide an internal documentation site, so my opinions are mostly theoretical.
I definitely think it would be wonderful if there build server sent out automated pull requests to fix dependency problems.
DrRacket scrolling works great now!! :tada: