Hello Sorry for being inactive. Had back to back exams .
Got free today. I implemented a new search feature in my app . Pushed the changes to heroku too. Please go through : sleepy-wave-33400.herokuapp.com/port/ There you can search any port with its name. Even just starting few characters would work. Thanks On 30 April 2018 at 23:30, Mojca Miklavec <[email protected]> wrote: > On 30 April 2018 at 18:47, Jackson Isaac wrote: > > On Mon, Apr 30, 2018 at 10:06 PM, Vishnu wrote: > >> Hey > >> > >> Repository names: > >> MacPorts-features? > >> Macportsinfo? > >> Or just simple > >> gsoc18? > > No, gsoc18 is a bad name since the idea is to use the project > afterwards as well and I don't like to rename it two years from now. > (We can decide to rename it one month from now, but not once people > start forking it etc.) > > > I was thinking about macports-portstatistics or macports-portstats. > > Or "macports-portinfo" as something inbetween? I'm somewhat reluctant > about "stat[istics]" because it's about much more than statistics. > > >> And also in the long term. Parser would be run only once in forever or > say a > >> year. > > No way. Parser needs to be run after each commit. Initially it could > be once per hour or so to simplify things and avoid hooks etc., but in > the long term it needs to be run immediately after GitHub notifies you > about the update. > > >> And before running the original db must be cleared. > >> > >> And then obvious question arise. What if a new port is added in > macports. > > > > You are on a right path I would say. We would want it to update after > > every port is added/updated > > and built. > > Indeed, if a new port is added, you need to update the database. More > important: also if a port is removed or if version changes etc. > > >> For that i would like to know the mechanics of new port addition. > > See one of recent pull requests: > > https://github.com/macports/macports-ports/pull/1694/files > > This commit will create a new Portfile with four subports > (py-waitress, py27-waitress, py35-waitress, py36-waitress), update a > bunch of existing ports and add a bunch of new subports to existing > Portfiles (py35-paste, py36-paste, ...) > > We could at the same time declare a few ports obsolete or delete some. > > You get all that info from Portindex (it could be useful if we could > get some kind of "differential Portindex"; I'm not absolutely sure how > port deletions are handled). > > >> I think before the new port is added. It is obviously built before > right? > > No. It is first added. Only once it is added it can be built on the > buildbot (a commit to repository triggers a build on the buildbot). > > >> So > >> maybe we can add some code there to update the table with a row when new > >> port is added. > > > > When a port is submitted, it is built by Travis CI and also our > > buildbots, > > Travis only builds pull requests, not actually commits. > > > which builds > > the port for mac 10.6 to 10.13 versions and gives the build status. We > > would be more > > interested in the status provided by the buildbot. > > I would ignore Travis builds for now anyway. It could be interesting > to add pointers to open pull requests for a particular port, but not > right now. Evidently your code needs to first update the database to > get the list of all new ports, information about successful or failed > builds would come later from the buildbot. > > > There could be a trigger or a listener which runs whenever a build job > > is initiated and then > > updates the DB on completion. I believe there would be some mechanism > > to know the status > > of each job. > > You can access the API from the buildbot to ask for status. But if you > don't have an entry for a particular port first, you might run into > troubles if you'll want to add build results without being able to > reference a port with that name. > > > Maybe someone more familiar with buildbot could share some insights ? > > In any case it would make a lot more sense to start with tens of > thousands old builds first and only once that is done add the latest > information as soon as it's available. There is a high chance that > things will change if we switch to buildbot version one (which might > happen in the meantime). > > Mojca >
