On Sat, Aug 15, 2015 at 1:08 AM, Pauli Virtanen wrote:
> 15.08.2015, 01:44, Chris Barker kirjoitti:
> [clip]
> > numpy doesn't use namespace packages, so develop mode works there.
>
> The develop mode is mainly useful with a virtualenv.
>
> Otherwise, you install work-in-progress development vers
15.08.2015, 01:44, Chris Barker kirjoitti:
[clip]
> numpy doesn't use namespace packages, so develop mode works there.
The develop mode is mainly useful with a virtualenv.
Otherwise, you install work-in-progress development version into your
~/.local which then breaks everything else. In addition
On Fri, Aug 14, 2015 at 10:15 AM, Stefan van der Walt
wrote:
> Perhaps mpl_toolkits should think of
> becoming mpl_3d, mpl_basemaps, etc.?
>
namespace packages are a fine idea, but the implementation(s) are just one
big kludge...
I think so, but we're getting off-topic here.
numpy doesn't us
On 2015-08-14 10:08:11, Benjamin Root wrote:
> I should also note that there is currently an open issue with
> "pip install -e" and namespace packages. This has been reported
> to matplotlib with regards to mpl_toolkits. Essentially, if you
> have namespace packages, it doesn't get installed co
I think it's clear that develop/-e does not work well together with
namespace packages. As noted on the relevant matplotlib issue
https://github.com/matplotlib/matplotlib/issues/4907 I think the issue with
namespace packages is essentially this well known one
https://github.com/pypa/pip/issues/3 wh
On Fri, Aug 14, 2015 at 10:08 AM, Benjamin Root wrote:
> I used to be a huge advocate for the "develop" mode, but not anymore. I
> have run into way too many Heisenbugs that would clear up if I nuked my
> source tree and re-clone.
>
well, you do need to remember to clean out once in a while, whe
On Aug 14, 2015 09:16, "Chris Barker" wrote:
>
> On Thu, Aug 13, 2015 at 11:25 AM, Stefan van der Walt <
stef...@berkeley.edu> wrote:
>>
>> >(for
>> > example "python setup.py develop", although suggested by
>> > setup.py itself, claims that "develop" is not a command).
>
>
> develop is a command
On 08/14/2015 01:52 PM, Pauli Virtanen wrote:
> 14.08.2015, 20:45, Allan Haldane kirjoitti:
> [clip]
>> Related to this, does anyone know how to debug numpy in gdb with proper
>> symbols/source lines, like I can do with other C extensions? I've tried
>> modifying numpy distutils to try to add the r
14.08.2015, 20:45, Allan Haldane kirjoitti:
[clip]
> Related to this, does anyone know how to debug numpy in gdb with proper
> symbols/source lines, like I can do with other C extensions? I've tried
> modifying numpy distutils to try to add the right compiler/linker flags,
> without success.
runte
On 08/13/2015 11:52 AM, Anne Archibald wrote:
> Hi,
>
> What is a sensible way to work on (modify, compile, and test) numpy?
>
> There is documentation about "contributing to numpy" at:
> http://docs.scipy.org/doc/numpy-dev/dev/index.html
> and:
> http://docs.scipy.org/doc/numpy-dev/dev/gitwash/
I used to be a huge advocate for the "develop" mode, but not anymore. I
have run into way too many Heisenbugs that would clear up if I nuked my
source tree and re-clone.
I should also note that there is currently an open issue with "pip install
-e" and namespace packages. This has been reported to
On Thu, Aug 13, 2015 at 11:25 AM, Stefan van der Walt
wrote:
> >(for
> > example "python setup.py develop", although suggested by
> > setup.py itself, claims that "develop" is not a command).
develop is a command provided by setuptools, not distutils itself.
I find it absolutely invaluable --
On 2015-08-13 08:52:22, Anne Archibald
wrote:
> My current approach is to build an empty virtualenv, pip install
> nose, and from the numpy root directory do "python setup.py
> build_ext --inplace" and "python -c 'import numpy;
> numpy.test()'". This works, for my stock system python, though I
On Thu, Aug 13, 2015 at 10:00 AM, Sebastian Berg wrote:
> On Do, 2015-08-13 at 15:52 +, Anne Archibald wrote:
> > Hi,
> >
> >
> > What is a sensible way to work on (modify, compile, and test) numpy?
> >
> >
> > There is documentation about "contributing to numpy" at:
> > http://docs.scipy.org
On Do, 2015-08-13 at 15:52 +, Anne Archibald wrote:
> Hi,
>
>
> What is a sensible way to work on (modify, compile, and test) numpy?
>
>
> There is documentation about "contributing to numpy" at:
> http://docs.scipy.org/doc/numpy-dev/dev/index.html
>
> and:
> http://docs.scipy.org/doc/num
Hi,
What is a sensible way to work on (modify, compile, and test) numpy?
There is documentation about "contributing to numpy" at:
http://docs.scipy.org/doc/numpy-dev/dev/index.html
and:
http://docs.scipy.org/doc/numpy-dev/dev/gitwash/development_workflow.html
but these are entirely focused on usi
On 10/12/10 10:33 AM, Charles R Harris wrote:
> On Tue, Oct 12, 2010 at 9:22 AM, Pierre GM wrote:
>
>>
>> On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote:
>>
>>> On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote:
All,
All my sincere apologies for the mess I caused... The changes I wa
On Tue, Oct 12, 2010 at 2:46 PM, Pauli Virtanen wrote:
> Tue, 12 Oct 2010 13:55:27 -0600, Vincent Davis wrote:
>>> It's meant for easy inclusion in other projects (if they agree with the
>>> worfklow it presents), here it is for example rendered with the urls
>>> pointing to ipython repos:
>>
>> H
Tue, 12 Oct 2010 13:55:27 -0600, Vincent Davis wrote:
>> It's meant for easy inclusion in other projects (if they agree with the
>> worfklow it presents), here it is for example rendered with the urls
>> pointing to ipython repos:
>
> Hope something like this gets converted/done for Numpy.
http:/
On 10/12/2010 01:55 PM, Fernando Perez wrote:
On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis wrote:
Lots of good reading :) Just thought I'd put a plug in for the
contributor that may make only a few contributions and needs a simple
workflow to do so. It would be great if they could just..
mak
On Tue, Oct 12, 2010 at 12:55 PM, Fernando Perez wrote:
> On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis
> wrote:
>> Lots of good reading :) Just thought I'd put a plug in for the
>> contributor that may make only a few contributions and needs a simple
>> workflow to do so. It would be great if
On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis wrote:
> Lots of good reading :) Just thought I'd put a plug in for the
> contributor that may make only a few contributions and needs a simple
> workflow to do so. It would be great if they could just..
> make there own fork
> clone the branch of int
On Wed, Oct 13, 2010 at 12:40 AM, Pierre GM wrote:
>
> On Oct 12, 2010, at 5:38 PM, David Cournapeau wrote:
>
>> On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote:
>>>
>>> git push
>>> The files created by setup.py develop are marked as not added but pollute
>>> some of the reports (diff, eg).
>
On Oct 12, 2010, at 5:38 PM, David Cournapeau wrote:
> On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote:
>>
>> git push
>> The files created by setup.py develop are marked as not added but pollute
>> some of the reports (diff, eg).
>
> I am still not following - generated files should certai
On Wed, Oct 13, 2010 at 12:31 AM, Pierre GM wrote:
>
> On Oct 12, 2010, at 5:28 PM, David Cournapeau wrote:
>>>
>>> I gonna try again in a couple of hours. Looks like I need to specifically
>>> exclude the files created by a `python setup.py develop`.
>>
>> Not sure I understand the link between
On Tue, Oct 12, 2010 at 9:22 AM, Pierre GM wrote:
>
> On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote:
>
> > On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote:
> >> All,
> >> All my sincere apologies for the mess I caused... The changes I wanted
> to commit were quite minimal (just a few line
On Oct 12, 2010, at 5:28 PM, David Cournapeau wrote:
>>
>> I gonna try again in a couple of hours. Looks like I need to specifically
>> exclude the files created by a `python setup.py develop`.
>
> Not sure I understand the link between git and python setup.py
> develop. What git command did yo
On Wed, Oct 13, 2010 at 12:22 AM, Pierre GM wrote:
>
> On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote:
>
>> On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote:
>>> All,
>>> All my sincere apologies for the mess I caused... The changes I wanted to
>>> commit were quite minimal (just a few line
On Oct 12, 2010, at 5:10 PM, David Cournapeau wrote:
> On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote:
>> All,
>> All my sincere apologies for the mess I caused... The changes I wanted to
>> commit were quite minimal (just a few lines in a test), but I obviously
>> included some stuffs I did
On Tue, Oct 12, 2010 at 6:06 PM, Pierre GM wrote:
> All,
> All my sincere apologies for the mess I caused... The changes I wanted to
> commit were quite minimal (just a few lines in a test), but I obviously
> included some stuffs I didn't want too...
No worries. Unless someone beats me to it, I
Lots of good reading :) Just thought I'd put a plug in for the
contributor that may make only a few contributions and needs a simple
workflow to do so. It would be great if they could just..
make there own fork
clone the branch of interest
make changes
push to there own fork
request pull.
I think
Tue, 12 Oct 2010 11:48:07 +0200, Pierre GM wrote:
[clip]
> Till I'm at it, would there be anybody patient to hold my hand and tell
> me how to backport changes from one branch to another?
I do it like this:
# create a local branch for integrating backports
# needs to be done only
On 12 October 2010 11:58, David wrote:
> On 10/12/2010 06:48 PM, Pierre GM wrote:
>>
>> Corollary: how do I branch from a branch ?
>
> You use the branch command:
>
> git branch target_branch source_branch
>
> But generally, if you want to create a new branch to start working on
> it, you use the
On 10/12/2010 06:48 PM, Pierre GM wrote:
>
> On Oct 12, 2010, at 11:32 AM, Matthew Brett wrote:
>>
>> I think the only possible lesson that might be drawn is that it
>> probably would have helped you as it has certainly helped me, to have
>> someone scan the set of changes and comment - as part of
On Oct 12, 2010, at 11:32 AM, Matthew Brett wrote:
>
> I think the only possible lesson that might be drawn is that it
> probably would have helped you as it has certainly helped me, to have
> someone scan the set of changes and comment - as part of the workflow.
That, and a nice set of instruct
Hi,
>> Does anyone disagree with Pauli's never-push-your-own-changes suggestion?
>
> I think it is a little too extreme for trivial changes like one-liner
> and the likes, but I think it is a good default rule (that is if you are
> not sure, don't push your own changes).
Well - but
a) if it's a
Hi,
> All my sincere apologies for the mess I caused... The changes I wanted to
> commit were quite minimal (just a few lines in a test), but I obviously
> included some stuffs I didn't want too...
Ah - no - so sorry that the discussion got attached to your original
post and problem.
I would l
On 10/12/2010 06:22 PM, Matthew Brett wrote:
> Hi,
>
>> I think there are two issues here:
>>
>> (A) How to be sensible and presentable
>>
>> (B) How and when your stuff gets into master
>
> A very useful distinction - thanks for making it.
>
>> For (A) I'm following the same workflow I had with th
Hi,
> I think there are two issues here:
>
> (A) How to be sensible and presentable
>
> (B) How and when your stuff gets into master
A very useful distinction - thanks for making it.
> For (A) I'm following the same workflow I had with the git mirror:
>
> 1. For *every* change, create a separate
All,
All my sincere apologies for the mess I caused... The changes I wanted to
commit were quite minimal (just a few lines in a test), but I obviously
included some stuffs I didn't want too...
Anyhow, I just reverted the commit, as David told me to, and see what I need to
do from there without w
Mon, 11 Oct 2010 16:47:23 -0700, Matthew Brett wrote:
> Am I right in thinking that for the moment at least, the git workflow is
> basically the same as the svn workflow (everyone commiting to trunk)?
I think there are two issues here:
(A) How to be sensible and presentable
(B) How and when your
On Mon, Oct 11, 2010 at 9:52 PM, Matthew Brett wrote:
> Sorry - just re-reading that - it's a bit cryptic. I mean, yes, I
> agree wholeheartedly that it's a shame to stick to svn workflows when
> using git. I'm just some guy as well of course. I suppose we
> just-some-guys should start an just
Hi,
>> In my opinion, I've seen a lot of people coming from SVN try to apply
>> SVN-style workflow to git (and presumably other dvcs's), but git and
>> the like (and Github!) allow for much more fine-tuned workflows in my
>> opinion, and I think it's a mistake to ignore that. I'm just some guy,
>>
Hi,
> I find having the branch displayed on the command line helpful in avoiding
> mishaps, so I have the following in my .bashrc
>
> export PS1='\[\033[1;31m\]\$\[\033[0m\...@\h \W$(__git_ps1 " (%s)")\\$ '
>
> The \W$(__git_ps1 " (%s)") bit is the important part.
Yes, that one's a lifesaver. It
Hi,
> In my opinion, I've seen a lot of people coming from SVN try to apply
> SVN-style workflow to git (and presumably other dvcs's), but git and
> the like (and Github!) allow for much more fine-tuned workflows in my
> opinion, and I think it's a mistake to ignore that. I'm just some guy,
> thou
On Mon, Oct 11, 2010 at 5:56 PM, Joshua Holbrook wrote:
> In projects I've worked on, most people have worked on their own
> repos, continually merging in changes from other repos to keep
> themselves current. I think this is generally a good approach for
> development, if a bit disorganized. In a
In projects I've worked on, most people have worked on their own
repos, continually merging in changes from other repos to keep
themselves current. I think this is generally a good approach for
development, if a bit disorganized. In addition, obviously a group of
people pushing to numpy/numpy is ne
Hi guys,
Am I right in thinking that for the moment at least, the git workflow
is basically the same as the svn workflow (everyone commiting to
trunk)?
I realize that this is not going to cheer anyone up, but is this the
best workflow now? Who would decide?
Best,
Matthew
_
48 matches
Mail list logo
