I’m trying to get HttpServer to run on v0.7. It crashes because it attempts to use Base.TCPServer. Per the Julia docs, that has been moved under the Sockets module.
However, attempting to add using Sockets to the HttpServer module crashes.
ERROR: LoadError: ArgumentError: Module Sockets not found in current path.
Run `Pkg.add("Sockets")` to install the Sockets package.
Stacktrace:
[1] require(::Module, ::Symbol) at ./loading.jl:868
[2] include at ./boot.jl:314 [inlined]
[3] include_relative(::Module, ::String) at ./loading.jl:1071
[4] include(::Module, ::String) at ./sysimg.jl:29
[5] top-level scope
[6] eval at ./boot.jl:316 [inlined]
[7] eval(::Expr) at ./client.jl:394
[8] macro expansion at ./none:3 [inlined]
[9] top-level scope at ./<missing>:0
in expression starting at /Users/adrian/.julia/packages/HttpServer/ZGld/src/HttpServer.jl:11
1 Like
Not sure, but I suspect this is just the fact that Pkg3 requires you to actually specify all of your dependencies (even, it would seem, on stdlib packages). See Problem with reassignment of uuid when a package is registered - #18 by kristoffer.carlsson
Can you pkg> add Sockets in the HttpServer project and see if that helps?
Thank you - yes, that’s right.
pkg> add wasn’t enough (as far as I can tell). I had to do a pkg> develop HttpServer first.
1 Like
Related to this, I keep bumping into this design problem as I upgrade my codebase to 0.7.
I have an ORM (SearchLight) which supports multiple backends (MySQL, SQLite, etc). I would like to avoid having all the backends as package dependencies (otherwise the user will have to install all of them, despite needing just one). But asking the user to do a pkg> add MySQL or adding MySQL to her project is not enough, is it? It seems that a user of SearchLight would have to add MySQL as a dependency of SearchLight as well?!
Also, it seems that doing a pkg> add will overwrite the Manifest.toml for packages which are being checked-out with pkg> develop and changes in dependencies are lost.
This PR may end up fixing this issue:
https://github.com/JuliaLang/Pkg.jl/pull/357
We use a regex to figure out what the stdlib dependencies of packages are when generating the registry from METADATA.jl since stdlib dependencies aren’t explicitly recorded anywhere. That script was not including Sockets. This fix still needs to get propagated to the machine that does the actual syncing, however, so it will take a little time. cc @kristoffer.carlsson
There’s a design for an “alternates” mechanism in Pkg3 but it’s not yet implemented. Until then, you’ve got to jump through some hoops to make this work. The easiest thing is to just declare a dependency on all of the backends you support. The trickier thing would be to load it via its name and UUID, but we don’t have an official way to do that at this point.
So does that mean that stdlib dependencies don’t need to be explicitly added with pgk> add to be available with using?
Looks like this was a different issue—the version of the script that has been generating the registry has Sockets in it still.
No, they do need to be added as explicit dependencies. This is just because the old package manager has no record of stdlib dependencies so we have to figure out which stdlibs a package depends on. It’s somewhat annoying to need to add stdlibs as dependencies, but after discussion, the conclusion was that making stdlibs as much like normal packages that happen to ship together with Julia itself was the way to go. And this will allow us to make breaking API changes in future Julia releases without breaking people’s old code as long as that code is explicit about which version of stdlibs it depends on (i.e. in a manifest file).
I see - I will do that, thank you. Wondering what effect will this have on similar architectures, like Plots.jl for example. Curious how they’ll handle the various backends.
We’ll have some way to handle this in 0.7 final, it’s just not ready yet.