[matplotlib-devel] get_sample_data and transitioning to git
A while ago, John Hunter wrote: > We'd like to transition our VCS to git, and this impacts our release > schedule because of the "get_sample_data" support in the trunk which > currently pulls the data from svn but would have to be refactored to > pull from [git] and we'd like to make the transition before we do a > release. Has it been decided where the master repository would be hosted? The current code seems to handle at least github just fine if you just replace the base URL in cbook.py: -baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/' +baseurl = 'http://github.com/jkseppan/mpl-sample-data/raw/master/' (I just created that repository for testing purposes, and made a small change to a file when testing, so it shouldn't become the final repository.) The code is really not specific to any version control system, but just assumes that the files can be retrieved from an HTTP server that has some basic conditional-get support. -- Jouni K. Seppänen http://www.iki.fi/jks -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] get_sample_data and transitioning to git
John Hunter writes: >> Has it been decided where the master repository would be hosted? The >> current code seems to handle at least github just fine if you just >> replace the base URL in cbook.py: > > We've been planning on using github. I'm surprised the existing code > works -- have you tested to see whether the cacheing w/ revision > number works under github, ie it only pulls down new data when the > revision number changes? Yes. The code is essentially a simple HTTP client, and it works right on account of the logic at the server. The server sets an ETag header when it sends a file, and on further requests replies with 304 Not Modified if the client knows the current ETag value, or with 200 OK if the value is stale. For example, running the date_index_formatter.py example with verbose=debug and an empty cache directory: ViewVCCachedServer: files listed in cache.pck: set([]) ViewVCCachedServer: files in cache directory: set([]) ViewVCCachedServer: retrieving http://github.com/jkseppan/mpl-sample-data/raw/master/aapl.csv ViewVCCachedServer: received response 200: OK loading /Users/jks/.matplotlib/sample_data/aapl.csv Next run: ViewVCCachedServer: files listed in cache.pck: set(['/Users/jks/.matplotlib/sample_data/aapl.csv']) ViewVCCachedServer: files in cache directory: set(['/Users/jks/.matplotlib/sample_data/cache.pck', '/Users/jks/.matplotlib/sample_data/aapl.csv']) ViewVCCachedServer: retrieving http://github.com/jkseppan/mpl-sample-data/raw/master/aapl.csv ViewVCCachedServer: received response 304: Not Modified ViewVCCachedServer: reading data file from cache file "/Users/jks/.matplotlib/sample_data/aapl.csv" loading /Users/jks/.matplotlib/sample_data/aapl.csv Then, after committing a new version in the repository: ViewVCCachedServer: files listed in cache.pck: set(['/Users/jks/.matplotlib/sample_data/aapl.csv']) ViewVCCachedServer: files in cache directory: set(['/Users/jks/.matplotlib/sample_data/cache.pck', '/Users/jks/.matplotlib/sample_data/aapl.csv']) ViewVCCachedServer: retrieving http://github.com/jkseppan/mpl-sample-data/raw/master/aapl.csv ViewVCCachedServer: received response 200: OK loading /Users/jks/.matplotlib/sample_data/aapl.csv -- Jouni K. Seppänen http://www.iki.fi/jks -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)
On 04/23/2010 02:44 AM, John Hunter wrote: > On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi wrote: >> Hello all, >> in some time (let's say a couple of months, maybe more) Debian will >> enter the "freeze" period, where no new upstream releases are >> accepted, in order to prepare the best stable release we can :) >> >> In the past months I see many changes are accumulated in the SVN but >> no new release are done. I don't know if you've already discussed >> about releasing mpl, but it would be nice if we can have something >> before the freeze, so to have a quite-update mpl in squeeze. >> >> > From my POV, I'll provide all the support needed, so if there >> something I can do just tell me :) > > Hey Sandro, > > thanks for the head's up. We would like to get a 1.0 release out and > there are two roadbumps we have to navigate first. We'd like to > transition our VCS to git, and this impacts our release schedule John et al., 1) It looks like numpy is about to make the jump to github. Their discussion includes interesting points of strategy. Their intention is to develop the strategy via an NEP. 2) If I understand correctly, a key question is who will have commit rights to the master repo on github. It seems that an exception is required to allow that access to more than one person. My sense is that ideally we should have more than one person with that access, but far fewer people than presently have svn commit access. Those with access would then be asked to pull changes into the master from other people's clones--which would be github branches under their control. 3) Is it really a good idea to delay the release until the we make the github transition? Given how long it has been since a release, and the possibility that there will be some turbulence until we have had some experience with github, I think it would be better to release first and transition immediately afterwards. Eric > because of the "get_sample_data" support in the trunk which currently > pulls the data from svn but would have to be refactored to pull from > hit and we'd like to make the transition before we do a release. > Andrew, who is handling the git transition, has been very tied up of > late, but thinks he'll have some time in early May. The other issue > is my dead OSX build box -- I have access to a 64bit python 2.6 > platform for builds for OSX, but currently no other platforms/versions > so I have to sink some time into this for a release, though this is > not a show stopper as we could do a release with incomplete binary > support for OSX. > > So keep our feet to the fire and make sure we don't fall too far > behind so we can get something out before the freeze, hopefully far > enough before the freeze that we can get at least one bugfix release > out... > > JDH > > -- > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] QuadMesh zorder
On 05/28/2010 10:00 AM, Ryan May wrote: > Hi, > > Ben Root gave me a bug report that pcolormesh (and hence QuadMesh) > were not respecting zorder. This turns out to be due to the fact that > kwargs are not being forwarded on as appropriate. This is easy enough > to fix and make work, but I wanted to first ask for any insight on the > following "helpful" comment in axes.py: > > collection = mcoll.QuadMesh( > Nx - 1, Ny - 1, coords, showedges, > antialiased=antialiased, shading=shading) # kwargs are not used > > (It's be great if this comment gave some actual reasoning rather than > stating the obvious). > > Anyone know if there's an explicit design choice for QuadMesh not > taking kwargs, or is it just an omission? > > Ryan > Ryan, I don't know based on any recollection of how the code got that way, but it certainly looks like a historical artifact, and not something that needs to be preserved. I think you should go ahead and change it. If no tests or examples break, then it looks safe enough. Eric -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upcoming Debian stable releaseand matplotlib new release(s)
On Sat, 29 May 2010 12:28:40 -1000, Eric Firing wrote: > 3) Is it really a good idea to delay the release until the we make the > github transition? Given how long it has been since a release, and the > possibility that there will be some turbulence until we have had some > experience with github, I think it would be better to release first and > transition immediately afterwards. I've had unanticipated time commitments come up that have limited the time I have available for work on MPL. I had been planning spending some time to facilitate a switch to git but now can't see where the time will come from (in the next several weeks at least). Therefore I think making a release before any VCS switch is a good idea. -Andrew -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)
Hi, > > 2) If I understand correctly, a key question is who will have commit > rights to the master repo on github. It seems that an exception is > required to allow that access to more than one person. My sense is that > ideally we should have more than one person with that access, but far > fewer people than presently have svn commit access. Those with access > would then be asked to pull changes into the master from other people's > clones--which would be github branches under their control. Multiple options (as far as I have understand github). You could use one account with multiple ssh-keys or you can add "contributors" to the repository in the repositorys Admin-panel, which I haven't tried out, yet. Regards, Malte -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
