From: Michael D. <md...@st...> - 2012-12-14 16:58:52
|
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 |
From: Nelle V. <nel...@gm...> - 2012-12-14 17:44:38
|
> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Nathaniel S. <nj...@po...> - 2012-12-14 17:55:58
|
On 14 Dec 2012 16:59, "Michael Droettboom" <md...@st...> 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? 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 |
From: Todd <tod...@gm...> - 2012-12-14 19:25:12
|
On Dec 14, 2012 5:59 PM, "Michael Droettboom" <md...@st...> 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 > Is there a reason pypi is not usable? > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Michael D. <md...@st...> - 2012-12-15 23:24:13
|
On 12/14/2012 02:25 PM, Todd wrote: > > > On Dec 14, 2012 5:59 PM, "Michael Droettboom" <md...@st... > <mailto:md...@st...>> 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 > > > > 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 |
From: Damon M. <dam...@gm...> - 2012-12-15 23:38:22
|
On Sat, Dec 15, 2012 at 5:24 PM, Michael Droettboom <md...@st...> wrote: > On 12/14/2012 02:25 PM, Todd wrote: > > > On Dec 14, 2012 5:59 PM, "Michael Droettboom" <md...@st...> 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 >> > > 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 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 -- 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 |
From: Thomas K. <th...@kl...> - 2012-12-15 23:47:57
|
On 15 December 2012 23:38, Damon McDougall <dam...@gm...>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. Thomas |
From: Damon M. <dam...@gm...> - 2012-12-15 23:53:31
|
On Sat, Dec 15, 2012 at 5:47 PM, Thomas Kluyver <th...@kl...> wrote: > On 15 December 2012 23:38, Damon McDougall <dam...@gm...> > 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. 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. -- 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 |
From: Eric F. <ef...@ha...> - 2012-12-16 00:20:20
|
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. > > 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 Mike, It doesn't sound like any of the standard alternatives is very suitable. Maybe Numfocus could provide the hosting directly? Eric |
From: Jason G. <jas...@cr...> - 2012-12-16 02:25:48
|
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). Thanks, Jason |
From: Michael D. <md...@st...> - 2012-12-17 12:41:54
|
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). > That's to say nothing of the upload interface, which is 10 times worse! :) Mike |
From: Damon M. <dam...@gm...> - 2012-12-16 19:21:58
|
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout <jas...@cr...> 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. -- 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 |
From: Todd <tod...@gm...> - 2012-12-16 19:38:56
|
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall <dam...@gm...>wrote: > On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout > <jas...@cr...> 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. |
From: Michael D. <md...@st...> - 2012-12-17 12:43:24
|
On 12/16/2012 02:38 PM, Todd wrote: > On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall > <dam...@gm... <mailto:dam...@gm...>> wrote: > > On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout > <jas...@cr... <mailto:jas...@cr...>> > 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. > > 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 |
From: Damon M. <dam...@gm...> - 2012-12-16 19:50:16
|
On Sun, Dec 16, 2012 at 1:38 PM, Todd <tod...@gm...> wrote: > On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall <dam...@gm...> > wrote: >> >> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> <jas...@cr...> 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: http://aws.amazon.com/s3/#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? -- 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 |
From: Eric F. <ef...@ha...> - 2012-12-16 20:45:07
|
On 2012/12/16 9:21 AM, Damon McDougall wrote: > On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout > <jas...@cr...> 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. > The github page https://github.com/matplotlib/matplotlib/downloads shows 44,000 downloads for the 1.2 tarball, so I don't think the 20,000 downloads per month limit of the free tier would work. Eric |
From: Damon M. <dam...@gm...> - 2012-12-17 06:07:40
|
On Sun, Dec 16, 2012 at 2:44 PM, Eric Firing <ef...@ha...> wrote: > On 2012/12/16 9:21 AM, Damon McDougall wrote: >> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> <jas...@cr...> 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. >> > > The github page https://github.com/matplotlib/matplotlib/downloads shows > 44,000 downloads for the 1.2 tarball, so I don't think the 20,000 > downloads per month limit of the free tier would work. Note: that's 44,000 downloads for a gzipped bundle of the *source*, which can still be downloaded via the "Tags" tab (https://github.com/matplotlib/matplotlib/tags). 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. -- 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 |
From: Michael D. <md...@st...> - 2012-12-17 12:37:11
|
On 12/16/2012 02:50 PM, Damon McDougall wrote: > On Sun, Dec 16, 2012 at 1:38 PM, Todd <tod...@gm...> wrote: >> On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall <dam...@gm...> >> wrote: >>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>> <jas...@cr...> 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: http://aws.amazon.com/s3/#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. 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. > > Matt, have you had experienced comitting binaries to the gh-pages > branch? Are there size limits? > 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. https://help.github.com/articles/what-is-my-disk-quota 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 |
From: Michael D. <md...@st...> - 2012-12-17 12:39:45
|
On 12/17/2012 07:36 AM, Michael Droettboom wrote: > On 12/16/2012 02:50 PM, Damon McDougall wrote: >> On Sun, Dec 16, 2012 at 1:38 PM, Todd<tod...@gm...> wrote: >>> On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall<dam...@gm...> >>> wrote: >>>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>>> <jas...@cr...> 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:http://aws.amazon.com/s3/#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. > > 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. 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 |
From: Michael D. <md...@st...> - 2012-12-17 12:49:56
|
On 12/17/2012 07:39 AM, Michael Droettboom wrote: > On 12/17/2012 07:36 AM, Michael Droettboom wrote: >> On 12/16/2012 02:50 PM, Damon McDougall wrote: >>> On Sun, Dec 16, 2012 at 1:38 PM, Todd<tod...@gm...> wrote: >>>> On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall<dam...@gm...> >>>> wrote: >>>>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>>>> <jas...@cr...> 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:http://aws.amazon.com/s3/#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. >> >> 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. > 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). 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 |
From: Michael D. <md...@st...> - 2012-12-17 13:10:14
|
On 12/16/2012 03:44 PM, Eric Firing wrote: > On 2012/12/16 9:21 AM, Damon McDougall wrote: >> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> <jas...@cr...> 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. I'll definitely walk down the hall and talk to my local Numfocus board member ;) As for S3, their free tier is clearly insufficient -- I thought I'd get a hold on the cost of paying for it. Our storage requirements are ~150MB per release (for all of the different binaries) (though likely to grow over time), so saying it's useful to have the last ~6 or so releases live at any given time, that's ~900MB -- let's call it 1GB. Our transfer requirements after a release seem to peak at around 1.7TB/mo, about 67,000 requests, after a release (though presumably amortized over time, it's lower). This is also likely to grow over time, of course. So, I think we've got: 1,700 GB transfer @ $0.12/GB = $204.00 70,000 requests $0.01/10,000 = $0.07 1GB storage @ $0.095 = $0.10 That's a bit steep to cover with donations alone. In any event, this is a useful assessment of what this is really worth (and what our eyeballs are worth to advertisers on Sourceforge ;) Perhaps, as Skipper suggests, with a little investment in automation tools for SourceForge that may remain the best option. The Sourceforge download experience isn't terrible if we provide direct links to the downloads on our own website. wxPython has done this for years, and AFAIK they have not run in to any problems. The links even work without a web browser (though, for example, wget and curl). Cheers, Mike |
From: Maximilian A. <max...@gm...> - 2012-12-17 13:33:40
|
2012/12/16 Thomas Kluyver <th...@kl...>: > On 15 December 2012 23:38, Damon McDougall <dam...@gm...> > 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. I haven't followed this thread in detail, so not sure if it's really relevant: I agree that it's quite messy, but it's definitely possible to find stable download links for automated downloads from sourceforge. I sometimes need this because I use a ports-like system for installing certain packages from source on top of my regular Ubuntu system, and it does work quite well. So if this is what's keeping people from Sourceforge then there are definitely workarounds (give me a shout if you need more specific information; I'm likely to have very sporadic internet access over the next few weeks though, so replies may take a while). However, I also think Sourceforge's interface is really ugly so if there are better alternatives then that's great. :) Cheers, Max |
From: Patrick M. <pat...@gm...> - 2012-12-17 15:11:24
|
I thought I would just throw this out there, and I'm not entirely sure it would work, but here goes... What about using something like Dropbox? Create a matplotlib account, put the binaries in a Public folder and then use that as the storage...I don't know how this would work in practice, but I do know that people have been using Dropbox to host things for websites in other venues (persontal blogs, etc) It's probably best to talk to Dropbox first, but since they are built on Python, they might be willing to work with open source Python projects. PTM --- Patrick Marsh Ph.D. Candidate / Liaison to the HWT School of Meteorology / University of Oklahoma Cooperative Institute for Mesoscale Meteorological Studies National Severe Storms Laboratory http://www.patricktmarsh.com On Mon, Dec 17, 2012 at 7:33 AM, Maximilian Albert < max...@gm...> wrote: > 2012/12/16 Thomas Kluyver <th...@kl...>: > > On 15 December 2012 23:38, Damon McDougall <dam...@gm...> > > 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. > > I haven't followed this thread in detail, so not sure if it's really > relevant: I agree that it's quite messy, but it's definitely possible > to find stable download links for automated downloads from > sourceforge. I sometimes need this because I use a ports-like system > for installing certain packages from source on top of my regular > Ubuntu system, and it does work quite well. So if this is what's > keeping people from Sourceforge then there are definitely workarounds > (give me a shout if you need more specific information; I'm likely to > have very sporadic internet access over the next few weeks though, so > replies may take a while). However, I also think Sourceforge's > interface is really ugly so if there are better alternatives then > that's great. :) > > Cheers, > Max > > > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Damon M. <dam...@gm...> - 2012-12-23 00:42:57
|
On Mon, Dec 17, 2012 at 8:10 AM, Michael Droettboom <md...@st...> wrote: > On 12/16/2012 03:44 PM, Eric Firing wrote: >> On 2012/12/16 9:21 AM, Damon McDougall wrote: >>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>> <jas...@cr...> 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. > > I'll definitely walk down the hall and talk to my local Numfocus board > member ;) At the 6th Annual Scientific Software Day here at UT Austin, I met and spoke to Travis Oliphant regarding funding for hosting our binaries. Travis has links with NumFOCUS and was eager to help the matplotlib community host binaries should we choose to not go with sourceforge or another free option. I'll need touch base with him again to get specifics, but I thought I'd just let everyone here know that that's still an option. To be honest with you, I'm thinking that if we only want to link to binaries from the matplotlib web page then sourceforge really doesn't sound like a bad option at all. -- 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 |
From: Nathaniel S. <nj...@po...> - 2012-12-23 19:24:49
|
On Sun, Dec 23, 2012 at 12:42 AM, Damon McDougall <dam...@gm...> wrote: > On Mon, Dec 17, 2012 at 8:10 AM, Michael Droettboom <md...@st...> wrote: >> On 12/16/2012 03:44 PM, Eric Firing wrote: >>> On 2012/12/16 9:21 AM, Damon McDougall wrote: >>>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>>> <jas...@cr...> 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. >> >> I'll definitely walk down the hall and talk to my local Numfocus board >> member ;) > > At the 6th Annual Scientific Software Day here at UT Austin, I met and > spoke to Travis Oliphant regarding funding for hosting our binaries. > Travis has links with NumFOCUS and was eager to help the matplotlib > community host binaries should we choose to not go with sourceforge or > another free option. > > I'll need touch base with him again to get specifics, but I thought > I'd just let everyone here know that that's still an option. > > To be honest with you, I'm thinking that if we only want to link to > binaries from the matplotlib web page then sourceforge really doesn't > sound like a bad option at all. Or -- I'll just point this out one more time then leave the dead horse alone :-) -- you could just register a project called 'matplotlib-downloads' on google code hosting, and have static URLs that look like e.g. https://apa6e.googlecode.com/files/apa6e-v0.3.zip and let Google foot the bill for reliable high-bandwidth CDN hosting. -n |