Closed Hritik14 closed 1 year ago
Hello,
May I suggest that those big refactors are made in a development branch?
We are rebasing regularly on main branch to follow the dev (and help on the proxy compatibility). We and were very surprised finding out that all the tests are currently broken.
I would suggest to reset to ed2131656b1b3030c2f9eb28e25c10dbbedc8e1d which is the last commit which has passed CI.
Hello @tardyp
May I suggest that those big refactors are made in a development branch?
We have gone through a major infrastructural change and any updates on the old codebase will need to be migrated. Accepting updates on the old structure would add to debts and slower migration. What do you think @pombredanne ?
We are rebasing regularly on main branch to follow the dev (and help on the proxy compatibility).
We've marked all proxy compatibility related issues with the networking label and are constantly communicating regarding the development in our gitter channel.
... and were very surprised finding out that all the tests are currently broken.
Other than nix, other active tests should be running. Could you post a log of broken active tests ?
@tardyp sorry for the inconvenience but there is no development branch... only one main branch and tags from there. What we could do is tag the last commit before this merge.
As maybe most of the potential users, it is difficult to really be contributing to opensource projects without actually getting short/middle term value from it.
I've not really dug into the current state nor looked at the details of this refacto, we can only trust you in the fact that this is necessary. I cannot really follow the status in gitter. chatrooms are not very efficient in getting a summary of the activities
Now we saw that there is a big refacto, and that most of the importers are just disabled.
In the current situation vulnerablecode disabled all of its value, and I am very sadned by that as this will not help new users to try it before contributing to it.
From a semi outsider point of view I can report my experience trying to make good use of it.
It is usual for opensource projects to not support proxy as it is hard to test, so that part is not an issue.
We however were surprised to see that a lot of importers just crashed when running them. We were asking ourself whether there was a production instance beyond ourself.
We contributed the fixes as much as we could including the github tag API. I don't know how someone could do a full import without that, as in my experience, the svn way to retrieve the info is just timing out for big projects.
Maybe I was a bit too enthousiastic and shouldn't have ignored the work-in-progress part in the project description.
I've not really dug into the current state nor looked at the details of this refacto, we can only trust you in the fact that this is necessary.
Yes, it was essential as otherwise we were creating either misleading or incorrect data or plain ignoring some.
I cannot really follow the status in gitter. chatrooms are not very efficient in getting a summary of the activities
Fair enough... FWIW this has been discussed almost weekly and reported in meeting notes for quite a while.
Now we saw that there is a big refacto, and that most of the importers are just disabled.
Yes, that's a temporary thing until we have progressively ported each of them to the new design. It is going to take some work and is not something that can be done in a day. But we are progressively porting each of them to the new design.
It is usual for opensource projects to not support proxy as it is hard to test, so that part is not an issue.
Actually part of the new design is to have one place where network operations are done and have all importers use it. This way it will be possible to have a single place where to configure a proxy. Today the network operations are all scattered in too many places.
We contributed the fixes as much as we could including the github tag API. I don't know how someone could do a full import without that, as in my experience, the svn way to retrieve the info is just timing out for big projects.
Yes this is much appreciated and the SVN way was a failed experiment indeed.
Maybe I was a bit too enthousiastic and shouldn't have ignored the work-in-progress part in the project description.
Bear with us! Let me tag the last release before this merge so we have a stable base for now.
@tardyp I pushed this tag that you can stick to for now https://github.com/nexB/vulnerablecode/releases/tag/v22.01
We have either migrated the importers listed here, or deprecated or added a follow up issue for same closing this, Feel free to re-open if needed.
Hi @tardyp @pombredanne @Hritik14 @TG1999 @tdruez I am Hammad, a current MS student in Artificial Intelligence. The proposed project aligns well with my technical expertise and interests, making me eager to explore its codebase and learn about its architecture and functionality. I am eager to contribute to the project For GSOC 2023. My immediate plans include setting up the project locally and familiarizing myself with its codebase. Fix some small issues. I would appreciate guidance in ensuring that I am heading in the right direction. Thank you for your consideration. A little bit about me: I'm an experienced Python backend engineer skilled in developing web applications with Django/Django Rest Framework. Proficient in creating efficient data scraping and automation tools using Python web scraping stack, and working with scientific computing libraries like Numpy, Pandas, Matplotlib, and Scikit-learn. Committed to delivering high-quality code and efficient solutions for complex problems. Looking forward to work with you. Thanks, Hammad
@Hammad-1 Thank you for your enthusiasm. This issues is not a forum for discussion beyond the matter at hand here! It would be best to discuss your GSoC interest on the public Gitter channel!
@pombredanne Sure
Old structure:
New structure:
After migrating each importer make sure to
Following need migration to the new framework: