Transfer EzXML.jl to JuliaIO?
Closed this issue · 10 comments
(I'm not sure where to open this discussion. I'll reopen this if there is any better place.)
I'm developing EzXML.jl on my repository, which is very similar to LightXML.jl but mostly a superset of LightXML.jl because ExXML.jl:
- manages memory,
- supports XPath,
- supports namespaces, and
- supports streaming.
It is still young compared to LightXML.jl but I'm already using it without noticeable issues for months. So, I think it would be nice to place EzXML.jl in JuliaIO like other file format packages.
Any thoughts?
It's actively maintained where it is, right? Unless you're worried about having multiple people be able to maintain it going forward, I don't think it needs to move. Having too many packages in a single organization can cause issues with CI queues, it's better to have things somewhat evenly spread out.
I don't agree with all the API choices EzXML made (I wouldn't use getindex for attributes myself), but it may be a better choice for some users.
Yes, I maintain it. I proposed transferring the package because I think it is underrepresented compared to LightXML.jl in the community. There are so many packages that depend on LightXML.jl while only two do on EzXML.jl. This may be partially because LightXML.jl is placed in the JuliaIO organization, which will get more attention than my repository. In my (not humble) opinion, EzXML.jl would be a better choice as I mentioned above.
This is a suggestion, not a request. If you don't find any reason to transfer it here, it's fine to me.
Just out of curiosity, @tkelman, why you don't like the idea of using getindex for attribute access?
The most effective way of getting people to use EzXML would be proposing PR's changing their code for them.
Attributes don't nest, you're only ever going to get a string out of it. Not worth syntax for that, when hierarchy is in the child elements. It may depend on the structure of what kind of documents you work with.
Okay, it makes sense. I'll close this issue if no further comments.
The most effective way of getting people to use EzXML would be proposing PR's changing their code for them.
For example take a look at https://github.com/JuliaPackaging/WinRPM.jl
it's using LibExpat, but LibExpat isn't precompile safe
we can't depend on libxml for that package, since that package is used to download libxml
Hmm how does LibExpat obtain its dependencies on various platforms?
oh it's downloaded by default.....
I'm thinking libxml2 might be a better choice...
it's substantially larger, but that's not a discussion for this repo