New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect Python dependencies #34

Open
piamancini opened this Issue Jul 2, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@piamancini
Contributor

piamancini commented Jul 2, 2018

with setup.py

@choldgraf

This comment has been minimized.

choldgraf commented Aug 8, 2018

other options that could be used in Python:

  • requirements.txt
  • environment.yml
  • pipfiles

This would be really helpful for the scientific python ecosystem as well :-)

@znarf znarf changed the title from support `http://setup.py ` in Python packages to Detect Python dependencies Aug 17, 2018

@znarf

This comment has been minimized.

Collaborator

znarf commented Aug 31, 2018

@choldgraf

This comment has been minimized.

choldgraf commented Aug 31, 2018

....what exactly does this entail? :-)

@znarf

This comment has been minimized.

Collaborator

znarf commented Aug 31, 2018

@choldgraf Looking at the existing implementations for Npm, Composer, Nuget and Dep: https://github.com/opencollective/backyourstack/tree/master/src/lib/dependencies Replicate one of these and adapt it to the Python ecosystem. Maybe by parsing requirements.txt to start?

@choldgraf

This comment has been minimized.

choldgraf commented Aug 31, 2018

Do all of the different pieces of info (e.g. requirements, package name, etc) need to be in the same file? For example, requirements.txt is a list of dependencies but no name (or other) information about the project. If the answer to this is "yes" then setup.py, pipfile, or environment.yml would be better, I think

@znarf

This comment has been minimized.

Collaborator

znarf commented Aug 31, 2018

At the moment, we only need to retrieve the list of dependencies, and the expected format is simply an array of strings such as ['celery', 'marshmallow', 'spyder'].

@choldgraf

This comment has been minimized.

choldgraf commented Aug 31, 2018

ah ok - I looked at the template and found, e.g., this: https://github.com/opencollective/backyourstack/blob/master/src/lib/dependencies/_template.js#L25

which made me think we have to be able to calculate the project name from each of the dependencyfiles. Or do we assume that the /* file */ inputs are an array of filenames so we may choose which to use?

@znarf

This comment has been minimized.

Collaborator

znarf commented Aug 31, 2018

The project name is optional, and is only relevant in the case of file upload. When doing through GitHub, we just use the name of the repository. When doing file upload, if it's not possible to detect it, we'll just display 'Unknown project name' and that's fine.

@choldgraf

This comment has been minimized.

choldgraf commented Aug 31, 2018

Gotcha, and how can we handle multiple files present at once? Not an issue if it only supports reqs.txt but if more are supported its common to have, eg, both setup.py and reqs.txt

@znarf

This comment has been minimized.

Collaborator

znarf commented Aug 31, 2018

@choldgraf the problem is that the more file you're looking into the slower it will be. In the Nuget implementation, if nothing is found in the first file, then it's falling back to the another one. Not sure the logic that make sense here, if you want to apply the same fallback strategy or if you want to merge the result of all files together.

@choldgraf

This comment has been minimized.

choldgraf commented Aug 31, 2018

nah I think having a "try X first and if not try Y" approach is fine. I'll look at nugat to see how they do it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment