Repo2docker: Automatically try running pip install in root dir

[kmader]

There are a number of packages on github that it would be useful to test with Binder. It would be great if there was a mode for automatically trying to run pip install . if a setup.py file is present

[willingc]

Thanks for the suggestion @kmader. I'll tag this issue for discussion.

[yuvipanda]

Tagging @minrk, who I remember as not wanting to do this a while back.

On Tue, Mar 13, 2018 at 12:56 PM, Carol Willing [e-mail]
wrote:

Thanks for the suggestion @kmader https://github.com/kmader. I'll tag
this issue for discussion.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jupyter/repo2docker/issues/249#issuecomment-372797813,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23loBl73dpuVbh2gpBzgQ68LeTjXpks5teCR9gaJpZM4Sa2HY
.

--
Yuvi Panda T
http://yuvi.in/blog

[minrk]

I'm not sure! For instance, if I had a binder link for my own package, I might want it to demo the current stable version, rather than the git version. Or I might want exactly this! I think the key thing is that this shouldn't be unconditional, there needs to be a way to avoid running setup.py. It's possible that the presence of a binder directory is sufficient to ignore the top-level setup.py.

It's also possible for a requirements.txt to include the current package, e.g. in binder/requirements.txt you can have -e .. and it will install the current package. This makes it opt-in rather than automatic, though.

[betatim]

I like the -e .. idea. In particular because it is opt-in

[kmader]

So my initial idea was so that I could just paste the github url of a cool new python package (or R package) into mybinder.org and have it work. For the binder-aware / elite, they could have their own environment / requirements / postBuild to control what happened to the package. It would just make it a lot easier to play around with new exciting packages on github. As now I have to fork it, add the postBuild and then run it.

[minrk]

I think it's a good idea to take a sampling of some package repos and see how we do detecting setup.py. It may make sense to do this.

Something to try:

• add setup.py to the PythonBuildPack's detect (so a requirements.txt will be installed as well, and should be first)
• never run setup.py if there's a binder directory

[minrk]

289 implements the above proposal (thanks @GladysNalvarte!). Before merging, I'd like it if people gave it a test on repos like ipython/ipython pandas-dev/pandas, jupyter/notebook, and any others people would like to try, to see how often it seems to work.

[GladysNalvarte]

@minrk, I have tested this modification and it works well for: ipython/ipython, ipython/ipykernel, matplotlib/matplotlib, jupyter/dashboards, python-visualization/folium, quantopian/qgrid, bloomberg/bqplot, jupyter-widgets/ipywidgets.
The image was not built for: scipy/scipy, pandas-dev/pandas and Jupiter/notebook but the problems are not related to this modification.

[GladysNalvarte]

The additional repos that work are: tornadoweb/tornado, micheles/decorator, pallets/jinja, ipython/traitlets, mink/kubespawner, kennethreitz/setup.
The ones that did not work: bokeh/bokeh, jupyterhub/jupyterhub, minrk/tornado, pypa/setuptools.

[minrk]

closed by #289