matplotlib-devel Mailing List for matplotlib

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

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

I'm very pleased to announce the first release candidate for Oscopy
v0.71. For those just tuning in, Oscopy is a plotting program based on
IPython for viewing and post-processing results of electrical
simulations (more details on oscopy website [1]). Documentation can be
found here [2].
Main user-visible change of this version:
* Support for new input data format: spice2, spice3, touchstone, ...
* New zooming functions: mouse-wheel support, x10 mode, span
* Figure windows reworked: new operation bar, scrollbars for panning
* Command line options restored: batch mode, interactive, quiet
* Duplicate Signals are renamed on file reading
* Update of User Manual
* Now installation is needed to run oscopy.
Main developer-visible changes:
* Separation between back-end (oscopy) and front-end (ioscopy)
And of course a lot of bug fixes.
Significant improvements were performed on the look and feel of the
graphical interface and input file formats. Before releasing the v0.71 I
eagerly need a feedback on those changes to make sure I'm going in the
right direction, this is why I announce a RC here.
I would really appreciate if you could give a try to this version: check
out this RC, verify it installs correctly, and test it. I kindly ask you
to report any bugs on oscopy-dev mailing list
(mailto:osc...@os...) in CC of this message.
The source code is hosted at repo.or.cz: http://repo.or.cz/w/oscopy.git
My apologies for the multiples posts.
Arnaud.
[1] http://oscopy.org
[2] http://oscopy.org/wiki/_media/oscopy/ioscopy-manual-071.pdf

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

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