I think the ease of `Pkg.clone` for packages that aren't yet ready for metadata is the biggest argument against an "extra metadata" thing. Especially since `Pkg.clone` already handles reading the REQUIRE file in the repo.
Maybe the thing to do is to advertise the steps to have people try your code? I think the steps are: 1. Repo on github in Pkg format (src folder, REQUIRE file, LICENSE file) 2. README with some install & usage instructions 3. Announce to julia-users with a description of what it is, why to use it, link to repo The main problem is discoverability, which is also a problem with registered packages, which means a second package listing won't solve it. Google does a reasonable job of indexing github readmes, so encouraging packages to start with a couple sentences describing the package for a context-free reader might be a way to improve "searchability" at least. -- Leah On Tue, Jul 1, 2014 at 8:57 PM, Randy Zwitch <[email protected]> wrote: > This doesn't seem like a great idea to me. I felt a great sense of > accomplishment when I had my first package listed on METADATA, as I felt > like I made a tangible contribution to the community (in the same way I'm > proud of having a CRAN package). So for me, I'd question the value of > having a package that's "sort of ok, but I'm not confident in it, and maybe > I'll update it if someone compliments me or submits a pull request to > extend the package..." It just seems so passive, when the barrier is > actually pretty low to getting a package on METADATA (compared to the > beatings that CRAN hands out). > > There's going to be good code and bad code, and having the hook into > GitHub provides a great mechanism for continuous improvement. The Julia > community is the friendliest that I'm a part of, but maybe we just need to > do more to have people believe in themselves. > > What I do think we need is a better way to discover packages. For example, > I had no idea what Nettle was until Viral (?) clued me into it having > crypto functions. > > > > On Tuesday, July 1, 2014 9:07:47 PM UTC-4, 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? >> >
