As someone who is a relative newcomer preparing packages for submission to
METADATA, I'm also inclined to agree with the above posts. When I first
started using Julia I was under no illusions that what's in METADATA may
not necessarily be sanctioned by the core julia developers and caveat
emptor applies.
On Wednesday, July 2, 2014 1:07:47 PM UTC+12, Iain Dunning wrote:
>
> Hi all,
>
> Something that came up in some discussions I had at *JuliaCon* is that
> people perceive packages in METADATA as being for more "serious" packages,
> i.e. by being there there is an implication of a certain minimum quality. A
> lot of my efforts in the package ecosystem have been try to help package
> developers to live up to that expectation. A consequence of this perception
> is that some people might be averse to list their work on METADATA, for
> fear its not good enough/not ready.
>
> You can currently list a package on METADATA with:
> - a version 0.0.0, which was the preferred way originally but is now
> discouraged. This tagged version's hash would be updated as needed (i.e. it
> doesn't follow master)
> - a listing with no tagged version, which allows someone to do
> Pkg.add("YourPkg") and automatically get the most up-to-date version of
> your package.
>
> Of course, you pretty much need to announce your package somewhere other
> than METADATA to let users know it exists, and users can you
> Pkg.clone("..") almost as easily as Pkg.add("..") with a no-version
> listing. Currently pkg.julialang.org doesn't show packages without a
> version, so the no-version listing is of limited utility for
> discoverability.
>
> A proposal that came up a few times at the conference was for some sort of
> METADATA-EXTRA, which only has versions of packages without version numbers
> and is open to everyone and anyone. It'd be super easy to add packages -
> simply add a name and URL to a list. Perhaps it could be accessed through a
> package not in Base, e.g. PkgExtra.
> It would have
> PkgExtra.update_listing() - refresh local list of package names and URLs
> PkgExtra.add(pkgname..) - git clone a package to ~/.juila/v0.x/
> PkgExtra.update(pkgname...) - git pull the packages
> PkgExtra.rm(pkgname...) - nuke the packages
> So basically, super simple. User could even be responsible for satisfying
> any dependencies of the packages installed this way. At the most, the
> REQUIRE in the package should be used, to keep this system as light-weight
> as possible.
>
> So this wouldn't be much work to get going, but I was more curious to see
> if there is actually demand for this. I'm worried its one of those things
> people say they want, but I'm not sure if the demand is real. This might be
> bad just in that it "forks" METADATA sort of, which is possibly not a great
> idea for a new package. On the plus side, it could encourage even more
> development and sharing.
>
> Thoughts?
>
