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