"Improvements" might mean up to and including complete replacement. The main thing I'd want to be sure we keep is having a mechanism for uploading automated nightly results from PackageEvaluator, building the pulse page http://pkg.julialang.org/pulse.html, etc.
On Wednesday, July 13, 2016 at 2:13:25 AM UTC-7, Adrian Salceanu wrote: > > Thanks Mosè! :) > > I think Tony's idea is the best way to go about it. This website is more > of a temporary patch as searching in pkg.julialang is inefficient (just > browser search with little context and then if something looks interesting > you have to open the repo, look around, get back, etc). Like I said, I'd > very much prefer to collaborate on building a modern and useful package > management and discovery ecosystem, something in the lines of > https://hex.pm or https://rubygems.org - rather than spread our limited > resources on similar projects. > > Tony, happy to help, but we need to get more specific about improvements. > If we're talking basic additions to the existing codebase, we can add > search capabilities as I also expose this data through an API (ex: > http://genieframework.com/api/v1/packages/search?q=tensorflow). If we're > talking about building a modern platform, similar to say hex.pm then it's > easier to extend the website I've built (as it's almost there). > > > miercuri, 13 iulie 2016, 09:04:51 UTC+2, Tony Kelman a scris: >> >> Regarding package keywords, that would be something to include in the >> Pkg3 manifest file, see https://github.com/JuliaLang/PkgDev.jl/issues/37 >> for initial thoughts. >> >> I'm pretty much maintaining pkg.julialang.org at the moment, we can >> certainly consider improvements. The website source is in the JuliaCI >> organization, as are the scripts that generate it (in PackageEvaluator.jl) >> nightly. >> >> >> On Tuesday, July 12, 2016 at 9:52:05 AM UTC-7, Mosè Giordano wrote: >>> >>> Hi Adrian, >>> >>> nice website! >>> >>> What I'd like to have in a Julia packages website is categories. This >>> would greatly enhances the possibilities for the users to find the package >>> they're looking for. Currently one must use search strings, but they may >>> not be very effective if the package author didn't use the exact words one >>> is using in the search. Of course this requires help from package >>> authors. I'm using a "keywords" cookie in the package comments like the >>> one suggested in Emacs Lisp conventions: >>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html#Library-Headers >>> >>> Maybe something similar can be implemented in METADATA.jl and Pkg.generate >>> could accept a category list as argument. We can choose a set of >>> "official" keywords that are listed in Julia packages websites. I hope >>> this will improve discoverability of packages. >>> >>> Bye, >>> Mosè >>> >>> >>> I've setup an early version of a Julia packages website, for your >>>> package discovery pleasure: http://genieframework.com/packages >>>> >>>> Fair warning, this is a test case website for Genie.jl, the full stack >>>> web framework I'm working on - and 90% of my focus was on building the >>>> actual framework and the app, rather than the accuracy of the data. >>>> >>>> That being said, the app works quite well as far as I can tell >>>> (feedback welcome!) and compared to pkg.julialang.org it has a few >>>> extra features: >>>> * full text search in README >>>> * it includes both METADATA registered packages and extra packages >>>> crawled from GitHub (not all Julia packages on GitHub are included, this >>>> is >>>> a know bug and I'm working on fixing it - but all the official packages >>>> are >>>> there). >>>> * lots of info at a glance, to help spot the best packages >>>> * modern UI >>>> >>>> If the core contributors (of whoever's maintaining pkg.julialang.org) >>>> think this can be a useful replacement for pkg.julialang.org I'm happy >>>> to donate it and contribute by extending it to add the missing features >>>> (license, tests status, etc) and maintain it. Let me know. >>>> >>>> Adrian >>>> >>>
