On Wed, Nov 23, 2016 at 4:32 PM, Nathaniel Smith <n...@pobox.com> wrote:

> On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker <chris.bar...@noaa.gov>
> wrote:
>


> > Please, please, let's figure SOMETHING our here - editable installs (or
> > "develop" installs) are a critical tool. Frankly, I don't know how anyone
> > can develop a package without them.
>
> Would a 'pip watch' command that watched your source tree and
> rebuilt/reinstalled it whenever you edited a file work for you?


probably, yes -- though that seems pretty inefficient -- I suppose ti could
be smart enough to only update the changed file(s), which wouldn't be too
bad.

as for rebuild -- setuptools' develop mode doesn't rebuild anyway -- you
have to rebuild by hand if you change anything that isn't pure python --
which frankly works fine, as extensions need o be rebuild anyhow.

What
> do you do for conda packages?


develop mode is for, well, developing -- so no need for a conda package,
you are working from source be definition, and conda is a packaging system,
not a build system (i.e. for python packages, conda build usually calls
setuptools (ideally via pip) to do the building anyway)

Does conda have an editable install
> equivalent?
>

despite what I said above, conda does have a develop command:

http://conda.pydata.org/docs/commands/build/conda-develop.html

It's needed because conda does some trickery with editing relative paths
for linking shared libs at install time. If you use setuptools' develop
mode with an extension module, it may find the wrong version of libs at run
time.

I honestly don't know how well it works -- I built my own kludge for my
stuff before it was ready to go:

https://github.com/NOAA-ORR-ERD/PyGnome/blob/master/py_gnome/re_link_for_anaconda.py

And this is a Mac only solution -- linking happens differently on Windows,
such that I think this is a non-issue, and not sure about Linux -- we are
deploying with conda on Linux, but I don't think anyone is developing on
Linux.


>  they make it harder
> to improve pip's infrastructure around upgrading, because upgrading
> requires pip to have a solid understanding of exactly what's
> installed. So it's absolutely possible to have some useful hack, like
> we do now, but useful hacks by their nature are hard to standardize:
>

True -- but I'd still rather a useful hack than nothing

standardization means "this is the final solution to this problem, it
> won't need further tweaking", and editable installs really feel like
> they might benefit from further tweaking. Or something.
>

maybe an officially marked as preliminary part of the standard?

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to