Now Pkg3/Pkg is the default package handler for 1.0, and Pkg depends on TOML, isn’t it odd that it’s unregistered and we have to install it separately if we want to use TOML ourselves?
Time and effort. @wildart did an early prototype using his own TOML parser implementation, which is the one bundled with Pkg3. The registered TOML parser didn’t handle some of the formats that we needed and it wasn’t worth spending time on TOML parsing with so much other work to do. At no point since then has it been a top priority to unbundle the TOML parser and finalize its API.
From Julia 0.7 / 1.0, it looks like stdlib/Pkg/ext/TOML Here is the modified version from @wildart to the latest Julia.
How about asking for PR to https://github.com/wildart/TOML.jl/?
By the way, Parsing TOML in latest Julia (0.7/1.0) is any way possible as bellow for now.
Note that the TOML inside Pkg is an implementation detail that is not considered stable. However, as been said, at some point it would be good to upstream the changes in there.
Its clear that you do not claim that it is stable (which is not done for any stdlib by the way) but the question remains: Can one use Pkg.TOML as a drop-in replacement for wildart/TOML.jl?
Seems not, I have a file that parsed fine with wildart/TOML.jl at julia 0.6 but does not with Pkg.TOML. But that should not be your problem.
I am curious if it is better migrating wildart/TOML.jl to 0.7 or taking Pkg.TOML as the start point. I will do this when no-one beets me to it (need to migrate several packages). Might be good to put this in JuliaIO.
julia> Pkg.TOML.parsefile("test.toml")
WARNING: Base.Pkg is deprecated, run `using Pkg` instead
in module Main
ERROR: MethodError: no method matching get(::String, ::String)
Closest candidates are:
get(::Any) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:63
Stacktrace:
[1] numdatetime(::Pkg.TOML.Parser{IOStream}, ::Int64) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:391
[2] value(::Pkg.TOML.Parser{IOStream}) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:723
[3] array(::Pkg.TOML.Parser{IOStream}, ::Int64) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:657
[4] value(::Pkg.TOML.Parser{IOStream}) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:719
[5] keyvalues(::Pkg.TOML.Parser{IOStream}, ::Pkg.TOML.Table) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:749
[6] parse(::Pkg.TOML.Parser{IOStream}) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/parser.jl:881
[7] parse(::IOStream) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/TOML.jl:32
[8] #open#298(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::typeof(Pkg.TOML.parse), ::String, ::Vararg{String,N} where N) at ./iostream.jl:369
[9] open at ./iostream.jl:367 [inlined]
[10] parsefile(::String) at /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v0.7/Pkg/ext/TOML/src/TOML.jl:46
I think that would be great. But I also understand why the authors of Pkg just worked on a copy directly: one can use TOML as a package, but that is tricky when the software in question is the package manager itself. I think that a viable solution would be having it in the standard libraries, but that also has trade-offs.