You forgot to remove pyglet from setup.py.

It's done now. I've removed pyglet from setup.py.

We should still specify a dependency on pyglet, but I think that we'd have to switch to distribute/setuptools for that.

I agree, pyglet doesn't belong to sympy. +1

Can you reference the issue numbers in the commit message?

@rlamy, is it possible to specify an optional dependency with those tools? I don't think we should require pyglet when 99% of stuff in SymPy works without it.

@asmeurer I've amended the last commit with the issue number for pyglet. I thought that the pull request message is documented (it seems I was wrong).

I can put whatever I want in the merge message if I merge through GitHub. The default is

Merge pull request #406 from Krastanov/pyglet

Moving Pyglet to an external dependency

i.e., it has the pull request number and the branch name, and the first line of the pull request title by default.

But you shouldn't rely on that, because if someone wants to know more about why pyglet was removed, they will find end up at the removal commit. So that is what should have the references in it.

I've also squashed the commits. Sorry for the messy work, I'm still getting used to git.

@asmeurer: we could specify it in extras_require. Unfortunately, pip doesn't support this, but I think it would still help packagers and downstream libraries.

Test results html report: http://pastehtml.com/view/ax18ir5dp.html

Automatic review by sympy-bot.

@rlamy I've added extras_require to setup.py and ./setup.py --dry-run install works, but please check it as I have just copied from the page you gave.

That doesn't do anything if we use distutils. We'd need to use the setup() function from Distribute/setuptools for it to work, but there are certainly more things to do if we switch to Distribute, and @vperic is working on it (right?). So for the time being, I'm +1 on your first commit and -0.5 on the new one.

I'll wait a bit and if no one says nothing new I'll revert it.

Yes, I'm working on distribute. I think I'll have it done by tomorrow/Wednesday. I'm still figuring out the nuances of the system and how to do it exactly, but it shouldn't be too hard.

In any case, definitely a +1 for adding an external dependency (for what it's worth.. something like +0.01 ;))

@rlamy and @vperic, I think about leaving the pull request as it is (including the last commit about extras_require so there is a reminder when changing to distribute).

If you disagree I'll revert the last commit and the pull request will be clear to go in.

I'm +1 on all of it going in.

@asmeurer, could we get this in?

So if I understand the extras_require correctly, it's for completely optional dependencies. If that's the case, we should also add numpy, scipy, matplotlib, and f2py (you can see where these are used from my recent import_module commits).

How exactly does it work? I mean, what commands to setup.py trigger it?

The current backend for setup.py is unable to use extras_require. rlamy expains it and gives a link with details in an earlier comment.

So the last commit is just a cosmetic reminder - it does not change anything in the behavior of setup.py (until we switch to another backend (I believe vperic is working on this)).

@asmeurer: Yes, it's for completely optional dependencies. Nothing in setup.py triggers it, but it allows some project to specify one of our optional dependencies as mandatory if they need it. So, in the interest of moving this along, lets ask @Krastanov to remove that last commit and just push in the pyglet removal, and then I'll add extras_require when I port to Distribute (which I basically have working in a branch, but want to do "right"). Ok?

I've just removed the last commit (reset --hard HEAD^ and push -f).

OK. I'm actually fine with extras_require so long as it does not require people to install pyglet to use SymPy. But go ahead and do all the dependencies with the Distribute stuff.

So I'll merge this.

By the way, when we release 0.7.0 and merge 0.7.0 back into master, this should be updated to use the new import_module function.

OK, I'll try to remember and do it when the time comes.

@asmeurer, you seem to have forgotten to fix a merge conflict in setup.py, this is what's currently in master:

<<<<<<< Updated upstream
# $ for i in `find * -name __init__.py |rev |cut -f 2- -d '/' |rev \
# |egrep -v "^sympy$|thirdparty" `;do echo "'${i//\//.}',"; done |sort
=======
# $ for i in `find sympy -name __init__.py | rev | cut -f 2- -d '/' | rev | egrep -v "^sympy$|thirdparty/" `; do echo "'${i//\//.}',"; done | sort
>>>>>>> Stashed changes

Seems to have been introduced with commit ade1881: Update shell command to generate modules list in setup.py (2502)

I've made a pull request with a small patch to fix this.

The request is #461

On 26 June 2011 15:39, vperic <
reply@reply.github.com>wrote:

@asmeurer, you seem to have forgotten to fix a merge conflict in setup.py,
this is what's currently in master:

<<<<<<< Updated upstream

$ for i in `find * -name init.py |rev |cut -f 2- -d '/' |rev \

|egrep -v "^sympy$|thirdparty" `;do echo "'${i////.}',"; done |sort

$ for i in `find sympy -name init.py | rev | cut -f 2- -d '/' | rev |

egrep -v "^sympy$|thirdparty/" `; do echo "'${i////.}',"; done | sort

Stashed changes

Seems to have been introduced with commit ade1881: Update
shell command to generate modules list in setup.py (2502)

Reply to this email directly or view it on GitHub:
#406 (comment)