Github has removed the ability to host binaries. They’ve removed
this feature without any apparent notification except on their blog
saying “it’s gone today”. And the suggested alternative is to use
paid services.
[https://github.com/blog/1302-goodbye-uploads](https://github.com/blog/1302-goodbye-uploads)
I had planned to complete our set of 1.2.0 binaries with a Python
3.2 from Russell Owen in the near future. So much for that.
Any thoughts? Do we go back to Sourceforge for our download
hosting? Is anyone familiar with any other services? Do we try to
piggy-back on what other scipy projects are doing?
Any thoughts? Do we go back to Sourceforge for our download hosting? Is
anyone familiar with any other services? Do we try to piggy-back on what
other scipy projects are doing?
Scikit-learn uses sourceforge.
Scikits-image doesn't provide download links on the website (except
for windows binary, hosted on someone's webpage), but uses pipy's
hosting services.
I think sourceforge is OK.
Cheers,
N
···
Mike
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net matplotlib-devel List Signup and Options
I don’t think other scipy projects are doing anything special here; numpy and scipy never stopped using sourceforge. If you wanted to lead the way on setting up some simple download hosting on S3 or whatever for scipy projects then you could probably get numfocus to pay the hosting costs. Alternatively I’d consider Google code before going back to sourceforge - IME the service is similar overall but without sourceforge’s horror of an interface.
-n
···
On 14 Dec 2012 16:59, “Michael Droettboom” <mdroe@…31…> wrote:
Github has removed the ability to host binaries. They’ve removed this feature without any apparent notification except on their blog saying “it’s gone today”. And the suggested alternative is to use paid services.
I had planned to complete our set of 1.2.0 binaries with a Python 3.2 from Russell Owen in the near future. So much for that.
Any thoughts? Do we go back to Sourceforge for our download hosting? Is anyone familiar with any other services? Do we try to piggy-back on what other scipy projects are doing?
Github has removed the ability to host binaries. They’ve removed this feature without any apparent notification except on their blog saying “it’s gone today”. And the suggested alternative is to use paid services.
I had planned to complete our set of 1.2.0 binaries with a Python 3.2 from Russell Owen in the near future. So much for that.
Any thoughts? Do we go back to Sourceforge for our download hosting? Is anyone familiar with any other services? Do we try to piggy-back on what other scipy projects are doing?
Mike
Is there a reason pypi is not usable?
···
On Dec 14, 2012 5:59 PM, “Michael Droettboom” <mdroe@…31…> wrote:
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
PyPI doesn’t support large enough files. (I’m not sure what the
limit is, but I’ve hit it every time). We have always hosted our
files elsewhere and then just had PyPI point to them.
Mike
···
On 12/14/2012 02:25 PM, Todd wrote:
On Dec 14, 2012 5:59 PM, "Michael Droettboom" <mdroe@...31... >
wrote:
>
> Github has removed the ability to host binaries. They’ve
removed this feature without any apparent notification except on
their blog saying “it’s gone today”. And the suggested
alternative is to use paid services.
>
> https://github.com/blog/1302-goodbye-uploads
>
> I had planned to complete our set of 1.2.0 binaries with a
Python 3.2 from Russell Owen in the near future. So much for
that.
>
> Any thoughts? Do we go back to Sourceforge for our
download hosting? Is anyone familiar with any other services?
Do we try to piggy-back on what other scipy projects are doing?
>
> Mike
>
This seems like a pretty big minus, especially considering the work
you and others have put in migrating everything over from Sourceforge.
Do you think it would be worth contacting the GitHub folks about this?
I'm not sure what I'm trying to achieve. I guess I'd like them to
realise that GitHub Downloads were a really useful feature and their
reasons for removing it without deprecation of the GitHub Uploads
process has made the distribution of matplotlib more confusing for our
users.
Perhaps it's better just to move on...
I've been (un?)fortunate enough to never have to use Sourceforge's
interface. If it's the case it's not intuitive then I like Nathaniel's
idea of hosting the binaries on Google Code. The downside of this, of
course, is that matplotlib is then spread across three different
services: Sourceforge for the mailing list; GitHub for the source and
development; and Google Code for the binaries.
Maybe the best thing is to host the binaries on Sourceforge.
To be honest, I'm not sure that the service that hosts the binaries
matters all that much. We could put links to the binaries on the
webpage and then it's completely transparent to the user.
Sorry for the stream of conscience.
Best wishes,
Damon
···
On Sat, Dec 15, 2012 at 5:24 PM, Michael Droettboom <mdroe@...31...> wrote:
On 12/14/2012 02:25 PM, Todd wrote:
On Dec 14, 2012 5:59 PM, "Michael Droettboom" <mdroe@...31...> wrote:
Github has removed the ability to host binaries. They've removed this
feature without any apparent notification except on their blog saying "it's
gone today". And the suggested alternative is to use paid services.
I had planned to complete our set of 1.2.0 binaries with a Python 3.2 from
Russell Owen in the near future. So much for that.
Any thoughts? Do we go back to Sourceforge for our download hosting? Is
anyone familiar with any other services? Do we try to piggy-back on what
other scipy projects are doing?
Mike
Is there a reason pypi is not usable?
PyPI doesn't support large enough files. (I'm not sure what the limit is,
but I've hit it every time). We have always hosted our files elsewhere and
then just had PyPI point to them.
Mike
--
Damon McDougall http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229
Having recently tried to do it, Sourceforge tries really hard to avoid
giving you a direct link that can repeatably be used to download a file
automatically, i.e. without a browser. In the case I was after it for, I
ended up downloading the file (a PyWin32 binary) with a browser, and
storing it on the CI server that I wanted to install it.
Thomas
···
On 15 December 2012 23:38, Damon McDougall <damon.mcdougall@...149...>wrote:
Maybe the best thing is to host the binaries on Sourceforge.
Thanks for that information, Thomas. I conclude hosting the binaries
on Sourceforge and just linking to them from the mpl website is not
feasible. Unless, of course, there is resistance to the idea of
linking to them from the website.
···
On Sat, Dec 15, 2012 at 5:47 PM, Thomas Kluyver <thomas@...1071...> wrote:
On 15 December 2012 23:38, Damon McDougall <damon.mcdougall@...149...> > wrote:
Maybe the best thing is to host the binaries on Sourceforge.
Having recently tried to do it, Sourceforge tries really hard to avoid
giving you a direct link that can repeatably be used to download a file
automatically, i.e. without a browser. In the case I was after it for, I
ended up downloading the file (a PyWin32 binary) with a browser, and storing
it on the CI server that I wanted to install it.
--
Damon McDougall http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229
It doesn't sound like any of the standard alternatives is very suitable. Maybe Numfocus could provide the hosting directly?
Eric
···
On 2012/12/14 6:58 AM, Michael Droettboom wrote:
Github has removed the ability to host binaries. They've removed this
feature without any apparent notification except on their blog saying
"it's gone today". And the suggested alternative is to use paid services.
I had planned to complete our set of 1.2.0 binaries with a Python 3.2
from Russell Owen in the near future. So much for that.
Any thoughts? Do we go back to Sourceforge for our download hosting?
Is anyone familiar with any other services? Do we try to piggy-back on
what other scipy projects are doing?
I'll second that. Every time I go to Sourceforge, I have to figure out how in the world to download what I want (and I have to figure out which things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
···
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout <jason-sage@...691...> wrote:
On 12/14/12 10:55 AM, Nathaniel Smith wrote:
sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
--
Damon McDougall http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229
Also, have you talked to the pypi people about making exceptions for really
popular projects? If critical packages like numpy, scipy, and matplotlib
cannot use pypi, that seems like a major failing of the system.
···
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall <damon.mcdougall@...149...>wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout > <jason-sage@...691...> wrote:
> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>> sourceforge's horror of an interface.
>
> I'll second that. Every time I go to Sourceforge, I have to figure out
> how in the world to download what I want (and I have to figure out which
> things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards
Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
Are you sure the monthly bandwidth limits are sufficient?
Here's the pricing: Cloud Object Storage - Amazon S3 - AWS. The free tier
programme limits are on there too. Unfortunately, I do not have the
knowledge to be able to say whether we would hit that or not.
Matt, have you had experienced comitting binaries to the gh-pages
branch? Are there size limits?
···
On Sun, Dec 16, 2012 at 1:38 PM, Todd <toddrjen@...149...> wrote:
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall <damon.mcdougall@...149...> > wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> <jason-sage@...691...> wrote:
> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>> sourceforge's horror of an interface.
>
> I'll second that. Every time I go to Sourceforge, I have to figure out
> how in the world to download what I want (and I have to figure out which
> things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards
Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
Are you sure the monthly bandwidth limits are sufficient?
Also, have you talked to the pypi people about making exceptions for really
popular projects? If critical packages like numpy, scipy, and matplotlib
cannot use pypi, that seems like a major failing of the system.
--
Damon McDougall http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
I was thinking that perhaps NumFocus would be running a server that could provide the hosting. Funding for an external service is also possible, though, and might make more sense.
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
Note: that's 44,000 downloads for a gzipped bundle of the *source*,
which can still be downloaded via the "Tags" tab
(Tags · matplotlib/matplotlib · GitHub). Any time one of us
creates a tag, GitHub automagically tar/gzips it and makes it
downloadable. As far as I am aware, this is separate to the
"Downloads" section, which is for arbitrary files of any type, not
just source tarballs.
That said, not taking into account the downloads of the tarball, we're
still pretty close to the 20,000 mark.
···
On Sun, Dec 16, 2012 at 2:44 PM, Eric Firing <efiring@...229...> wrote:
On 2012/12/16 9:21 AM, Damon McDougall wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> <jason-sage@...691...> wrote:
On 12/14/12 10:55 AM, Nathaniel Smith wrote:
sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
I was thinking that perhaps NumFocus would be running a server that
could provide the hosting. Funding for an external service is also
possible, though, and might make more sense.
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
--
Damon McDougall http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229
Since Nov 3, when 1.2.0 was released, we’ve used 1.7 GB of transfer
from the github download site. The S3 “free tier” limit of 1.5
GB/month is awfully close to that.
There used to be limits on github-pages specifically, but they seem
to have silently removed information about them. As for any github
repository, the limit is 1GB per repository.
We already have 375MB in our documentation (pages) repository. We
use about 150MB for all of the binaries for each release. So we’d
be able to squeeze about 3-4 releases in there before needing to
explicitly prune stuff. Additionally, the link above seems to
discourage hosting very large files in the pages repository – I
don’t know if that means they intend to not support them.
Mike
···
On 12/16/2012 02:50 PM, Damon McDougall
wrote:
On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote:
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
wrote:
On 12/14/12 10:55 AM, Nathaniel Smith wrote:
sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards
Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
Are you sure the monthly bandwidth limits are sufficient?
Also, have you talked to the pypi people about making exceptions for really
popular projects? If critical packages like numpy, scipy, and matplotlib
cannot use pypi, that seems like a major failing of the system.
Here's the pricing: . The free tier
programme limits are on there too. Unfortunately, I do not have the
knowledge to be able to say whether we would hit that or not.
Matt, have you had experienced comitting binaries to the gh-pages
branch? Are there size limits?
Oops – I totally misread the S3 requirements: it’s 15GB/month, so
we’re fine there, but as Eric pointed out, there’s also a 20,000
request limit per month, which we’re well over (we’ve have 67,500
requests since Nov 3’s 1.2.0 release).
Cheers,
Mike
···
On 12/17/2012 07:36 AM, Michael
Droettboom wrote:
Since Nov 3, when 1.2.0 was released, we've used 1.7 GB of
transfer from the github download site. The S3 “free tier” limit
of 1.5 GB/month is awfully close to that.
On 12/16/2012 02:50 PM, Damon
McDougall wrote:
On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote:
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
wrote:
On 12/14/12 10:55 AM, Nathaniel Smith wrote:
sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards
Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
Are you sure the monthly bandwidth limits are sufficient?
Also, have you talked to the pypi people about making exceptions for really
popular projects? If critical packages like numpy, scipy, and matplotlib
cannot use pypi, that seems like a major failing of the system.
Here's the pricing: . The free tier
programme limits are on there too. Unfortunately, I do not have the
knowledge to be able to say whether we would hit that or not.
That's to say nothing of the upload interface, which is 10 times worse!
Mike
···
On 12/15/2012 09:25 PM, Jason Grout wrote:
On 12/14/12 10:55 AM, Nathaniel Smith wrote:
sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
I don’t know if this is still the case, but having talked to one of
the people involved with PyPI a couple of years ago, my
understanding is that their infrastructure simply doesn’t support
it. They provide the ability to link to external files (which is
what matplotlib does now), and that is the standard solution to that
problem.
Cheers,
Mike
···
On 12/16/2012 02:38 PM, Todd wrote:
On Sun, Dec 16, 2012 at 8:21 PM, Damon
McDougall <damon.mcdougall@…149…>
wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
<jason-sage@...691... >
wrote:
> On 12/14/12 10:55 AM, Nathaniel Smith wrote:
>> sourceforge's horror of an interface.
>
> I'll second that. Every time I go to Sourceforge, I
have to figure out
> how in the world to download what I want (and I have
to figure out which
> things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance
towards Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting
directly’,
do you mean they would have the physical hardware to host
the files,
or are you suggesting they provide the finances to seek
hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try
that.
It's fairly inexpensive and the first year is free (within
monthly
bandwidth limits). We could try it for a year and see how
that pans
out? I'm not entirely sure how the Amazon stuff works but
I’ve heard
good things about it.
Are you sure the monthly bandwidth limits are sufficient?
Also, have you talked to the pypi people about making
exceptions for really popular projects? If critical
packages like numpy, scipy, and matplotlib cannot use pypi,
that seems like a major failing of the system.
And once again, writing e-mails before coffee is a bad idea
We’ve used about 1.7TB in the approx six weeks since the 1.2.0
release.
Mike
···
On 12/17/2012 07:39 AM, Michael
Droettboom wrote:
Oops -- I totally misread the S3 requirements: it's 15GB/month, so
we’re fine there, but as Eric pointed out, there’s also a 20,000
request limit per month, which we’re well over (we’ve have 67,500
requests since Nov 3’s 1.2.0 release).
On 12/17/2012 07:36 AM, Michael
Droettboom wrote:
Since Nov 3, when 1.2.0 was released, we've used 1.7 GB of
transfer from the github download site. The S3 “free tier”
limit of 1.5 GB/month is awfully close to that.
On 12/16/2012 02:50 PM, Damon
McDougall wrote:
On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote:
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall wrote:
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout
wrote:
On 12/14/12 10:55 AM, Nathaniel Smith wrote:
sourceforge's horror of an interface.
I'll second that. Every time I go to Sourceforge, I have to figure out
how in the world to download what I want (and I have to figure out which
things *not* to click on too).
Ok sounds like there is a reasonable amount of resistance towards
Sourceforge.
Eric, when you suggest that NumFocus could 'provide hosting directly',
do you mean they would have the physical hardware to host the files,
or are you suggesting they provide the finances to seek hosting
elsewhere?
In the GitHub blog post, they suggest using S3. We could try that.
It's fairly inexpensive and the first year is free (within monthly
bandwidth limits). We could try it for a year and see how that pans
out? I'm not entirely sure how the Amazon stuff works but I've heard
good things about it.
Are you sure the monthly bandwidth limits are sufficient?
Also, have you talked to the pypi people about making exceptions for really
popular projects? If critical packages like numpy, scipy, and matplotlib
cannot use pypi, that seems like a major failing of the system.
Here's the pricing: . The free tier
programme limits are on there too. Unfortunately, I do not have the
knowledge to be able to say whether we would hit that or not.
