-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
Update setup.py DOWNLOAD_URL #8205
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
Conversation
Changed the DOWNLOAD_URL string from the out of date SourceForge link to the current GitHub link.
Do we want to point to github, or to pypi, which contains binaries too:
https://pypi.python.org/pypi/scikit-learn
?
|
Oh I'm not sure. As long as it's up to date I'm indifferent. |
@NickGoumas, please remember to mention the associated issue in your PR description (I edited the PR for you this time). The best is to use "Fix #issueNumber", this way the issue gets closed automatically when the PR is merged. |
@GaelVaroquaux look at the associated issue. The link appears on PyPI so that would point to the page you are already in. To be honest I am not sure what DOWNLOAD_URL is supposed to be. |
As I said in the associated issue, it would be great to get rid of all the outdated sourceforge links across the whole code base. |
For the record download_url is not used in PyPA setup.py so maybe we can remove it. |
fwiw from when i edited the releases link in the README (#7637 (comment))
if we decide github should be the source for releases, maybe edit the readme as well? |
FWIW if you do decide GitHub, would recommend creating your own tarball and adding it to the published tags and have the URL point to that. The reason I suggest this is we learned at conda-forge last summer that GitHub generates their tarballs on the fly. So if the process for generating them changes, so does the checksum. This has happened a couple times to us in the last year and started occurring to us this year too. 😞 Publishing your own tarballs on GitHub would avoid this issue. Alternatively using PyPI avoids this issue as well. |
I am in favour of using PyPI and removing the DOWNLOAD_URL from setup.py unless someone sees a good reason to keep it there. |
@NickGoumas are you still working on this? |
@lesteve Is the consensus we just want to remove the DOWNLOAD_URL ? |
Nobody strongly complained, so I guess so. |
Ideally:
|
In the documentation for setup.py configuration its written that download_url .For conforming this I saw this blog-http://peterdowns.com/posts/first-time-with-pypi.html and also the official disutil documentation - https://setuptools.readthedocs.io/en/latest/setuptools.html. The mechanism they say is that it is one of primary parameters. When making a package and uploading it to pypi in the setup.py of package we must use the parameter ###The download_url is a link to a hosted file with your repository's code. Github will host this for you, but only if you create a git tag tl;dr: |
Thanks for taking a stab at this one. Because things have changed quite a bit in the past few years with python packaging, I think the most convincing thing to do would be to:
|
@lesteve I have tested we can upload successfully but when we install I am getting error: |
@shubham0704 did you install numpy? |
Oh my bad. But is there a provision to download required dependencies if not detected in the system. Like I used to make a requirements file while hosting a website -@nelson-liu.(I assumed that way) |
Changed the DOWNLOAD_URL string from the out of date SourceForge link to the current GitHub link. Fix #8184.
Reference Issue
What does this implement/fix? Explain your changes.
setup.py DOWNLOAD_URL is currently set to the out-of-date sourceforge link. This PR is updating that to the current GitHub link.
Any other comments?