Hi Giannis, On your first point, don't worry about having repositories for SWH -- if we were to do it, we will be pushing directly to the archive, using the "deposit" interface. Next, please don't spend time over-complicating the whole setup. There are a number of ways of updating the database information; even a simple cron line running a process weekly would be plenty. You definitely do not want to couple it tightly with the querying part -- why do it? Finally, yes, running docker images for the linux distributions is a nice way of being able to collect data from all of them. On Sun, Mar 28, 2021, at 05:34, John Pap wrote: > I meant that the alternative approach (i.e. the link to the compressed > sources) would be only used for those packages that have not yet been > archived via SWHID; I should have expressed it more clearly, apologies > for that. > In any case I totally agree that uploading those packages to the SWH > archive, and thus contributing to package archiving regardless of the > particular project, is a better approach. > Looking through the SWH API it is required to provide a link to a > Subversion, Mercurial or Git repository publicly accessible, so should > we temporarily create online public repositories to host the packages' > sources in some popular hub (Github, Bitbucket, GitLab etc), until the > archive process is completed ? > > As for the periodic update of the database in order to include newer > versions and new packages, would it be ok to use the Advanced Python > Scheduler <https://apscheduler.readthedocs.io/en/stable/index.html> > which can be combined with the popular python web frameworks ? > > Furthermore, regarding the package collection from multiple different > linux distributions I was considering using docker images of each > distribution that will run the necessary corresponding package > manager's commands. What do you think about that ? > > Lastly, I would like to ask you if there is a need to include UI > wireframes in the proposal. > > Warmly, > Giannis > > Στις Πέμ, 25 Μαρ 2021 στις 1:27 π.μ., ο/η Alexios Zavras > <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr>> έγραψε: > > Great to hear about the advances. > > > > The SWHIDs are the most stable constant identifier that can be used, > > so let's use these. Any other link is not guaranteed for long-term usage. > > > > In general: if a specific package is not present in the SWH archive,... > > we can simply upload it -- and make the archive better. > > > > FYI, if you are interested in the current state, all Debian packages > > are already in the archive and most of the Ubuntu ones are not (yet). > > > > On Thu, Mar 25, 2021, at 00:11, John Pap wrote: > > > Thanks a lot for your helpful guidance! > > > > > > Regarding the pointer to sources matter, I managed to fetch a package's > > > source code in an Ubuntu distribution using the apt-get source command > > > to locally fetch it and then generate its SWHID using the corresponding > > > cli tool. It's indeed an elegant way to refer to code archives that I > > > was not aware of. > > > However, I was wondering whether it's guaranteed that all packages' > > > sources have been archived via SWHIDs. > > > If the latter is the case, I was considering alternatively providing a > > > link to the compressed (in a tar.xz format) packages' sources in the > > > Ubuntu archive, so that the user can download and review them locally. > > > > > > I'm looking forward to your feedback! > > > Thank you in advance for your time, > > > Giannis > > > > > > > > > Στις Τρί, 23 Μαρ 2021 στις 1:56 μ.μ., ο/η Alexios Zavras > > > <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr> <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr <mailto:zvr%252Beellak [ at ] zvr [ dot ] gr>>> έγραψε: > > > > Well done on the collection of data! > > > > > > > > As I've written before. some of the ones you mention > > > > are crucial (e.g., name, version), some might be of interest > > > > (e.g., size, license), some are very difficult to handl > > > > (e.g. dependencies), and some are very distribution-specific. > > > > It's perfectly fine to start with a small set. > > > > > > > > One that definitely has to appear in our system > > > > is a pointer to the exact sources for each package. > > > > These can be generated by getting the source of the package > > > > and producing the SWHID for it. > > > > > > > > > > > > Oh, and to your last question, yes, apt(8) should not be > > > > the only supported way to get the information. > > > > Depending on the distribution, other equivalent > > > > commands will be used. Keep in mind that even > > > > older Debian systems do not have the "apt" command. > > > > > > > > On Mon, Mar 22, 2021, at 23:49, John Pap wrote: > > > > > Hello Sir, thanks for your clear response ! > > > > > > > > > > I was considering the same approach regarding the database > > > > > manipulation, i.e. that there will be append only operations. > > > > > I have also managed to retrieve various characteristics for all > > > > > available packages in an Ubuntu distribution, using the apt command; > > > > > namely the package name, version, size, category, dependencies, > > > > > homepage site, description, maintainer, architecture type, bugs site, > > > > > among others that are too technical and should better be omitted in my > > > > > honest opinion. Βut of course I would like to hear your point of view > > > > > as well. > > > > > Furthermore, I would like to ask you if there is a need to include > > > > > packages' info for non Debian based linux distributions that do not > > > > > support the apt command. > > > > > > > > > > Best Regards, > > > > > Giannis > > > > > > > > > > Στις Κυρ, 21 Μαρ 2021 στις 10:50 μ.μ., ο/η Alexios Zavras > > > > > <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr> <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr <mailto:zvr%252Beellak [ at ] zvr [ dot ] gr>> <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr <mailto:zvr%252Beellak [ at ] zvr [ dot ] gr> <mailto:zvr%252Beellak [ at ] zvr [ dot ] gr <mailto:zvr%25252Beellak [ at ] zvr [ dot ] gr>>>> έγραψε: > > > > > > Hi Ioannis, thanks for your interest in the project. > > > > > > > > > > > > You are absolutely correct: the info in the database > > > > > > will be collected independently of the web querying front-end. > > > > > > (whether there will be a RESTful API remains to be determined). > > > > > > > > > > > > You are also correct that there should be a mechanism > > > > > > for updating the database with new information. > > > > > > Given the nature of the data, it is probable that data > > > > > > will never be deleted, only added. > > > > > > So it would make sense to have the updating process > > > > > > add the data that is not already present in the database, > > > > > > rather than generating everything from scratch again. > > > > > > > > > > > > On Sat, Mar 20, 2021, at 23:52, John Pap wrote: > > > > > > > Greetings Everyone, > > > > > > > > > > > > > > My name is Papadopoulos Ioannis, I have graduated from the National > > > > > > > University of Athens and I'm currently pursuing my MSc in Web > > > > > > > Engineering. I have previously engaged with open source projects and > > > > > > > I'm highly interested in contributing to the particular project idea. > > > > > > > > > > > > > > Having carefully read the related threads, and please do correct me if > > > > > > > I'm wrong, I have concluded that the database containing all the > > > > > > > packages' info will be populated once and then the frontend will > > > > > > > retrieve the appropriate data from the backend (responsible for > > > > > > > querying the database) via a RESTful API. > > > > > > > However, I was wondering whether we would possibly want to periodically > > > > > > > repopulate the database, in order to include newer versions and new > > > > > > > packages. > > > > > > > > > > > > > > With Appreciation, > > > > > > > Papadopoulos Ioannis > > > > > > > > > > > > > > ---- > > > > > > > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και > > > > > > > συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του > > > > > > > Google Summer of Code - A discussion list for student developers and > > > > > > > mentors of Google Summer of Code projects., > > > > > > > https://lists.ellak.gr/gsoc-developers/listinfo.html > > > > > > > Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. > > > > > > > ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr> <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr>> <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr> <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%25252Bunsubscribe [ at ] ellak [ dot ] gr>>> > > > > > > > <mailto:gsoc-developers%2Bunsubscribe%40ellak.gr <mailto:gsoc-developers%252Bunsubscribe%2540ellak.gr> <mailto:gsoc-developers%252Bunsubscribe%2540ellak.gr <mailto:gsoc-developers%25252Bunsubscribe%252540ellak.gr>> <mailto:gsoc-developers%252Bunsubscribe%2540ellak.gr <mailto:gsoc-developers%25252Bunsubscribe%252540ellak.gr> <mailto:gsoc-developers%25252Bunsubscribe%252540ellak.gr <mailto:gsoc-developers%2525252Bunsubscribe%25252540ellak.gr>>>>>. > > > > > > > > > > > > > > > > > > > -- > > > > > > -- zvr - > > > > > > > > -- > > > > -- zvr - > > > > -- > > -- zvr - -- -- zvr -
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.