On the discoverability side, svaksha's curated collection really deserves more attention - it is categorized and provides short summaries of code ranging from listed packages to useful fragments that never showed up on the mailing lists.
http://svaksha.github.io/Julia.jl/ On Tue, Jul 1, 2014 at 10:38 PM, Leah Hanson <[email protected]> wrote: > 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? >>> >> >
