add note about --no-deps in develop mode.

[ChrisBarker-NOAA]

Adding a note about the no-deps option for develop mode -- I, at least, find this is usually what I want. (maybe because I use conda to handle dependencies...). but it took me a while to find it back in the day.

[qwcode]

I think we need a stated rationale as for why someone would do this, something besides mentioning conda, which is going to be a left-field remark for many people. installing dependencies is the natural thing. the exception I think we could mention is when they're using a dev requirements files that is handling dependencies for them.

[piotr-dobrogost]

the exception I think we could mention is when they're using a dev requirements files that is handling dependencies for them

This. After installing deps using requirements file I uninstall selected deps and install them in editable (in pip's parlance) mode with --no-deps option. Those are always selected deps which I'm interested in easy access to and I don't care about their dependencies.

[ChrisBarker-NOAA]

I agree we shouldn't mention conda. But frankly, --no-deps should be the default in develop mode. If you are developing, you want to control the dependencies your own way -- maybe some get installed in develop mode themselves, get them from a different source, have them installed by hand in a way that setuptools doesn't recognise...

But I'm not sure how to phrase that succinctly.

But then, I'm a bit pedantic -- I don't think setuptools should EVER install dependencies -- dependency management is what pip is for. And sometimes a setup.py install drags stuff in without your realizing quite what it did...

[qwcode]

we need to distinguish the following in our thread here:

1. whether to use setup.py develop or pip install -e .
2. whether --no-deps should be recommend and when

for #1, I think we should only be recommending pip install -e. currently, we mention both. we should change that I think.

#2 is a separate issue. I don't agree that --no-deps is the default recommendation, but I do understand the story of wanting to control which of your dependencies are also installed in editable mode, but I think the answer for that is about using a dev requirements file that overrides for those cases, not just using --no-deps and filling it all in yourself.

[ChrisBarker-NOAA]

can you use `--no-depswithpip install -e`` ? or another way to spell it?

If so, only mentioning pip install -e`` is fine. "there should only be one way to do it"

I'm not going to make a fuss about what the default recommendation should be - I just wanted the no-deps option to be there so it's easy to find for others to use if they want.

For my part, I was quite surprised when setup.py develop started downloading and installing stuff. This doc does currently mention that, which is great, but it might as well mention how to turn it off, too.

[qwcode]

You can do pip install -e . --no-deps

I'll post another PR later tonight that I hope will serve your need but
also cover the use of dev requirements files.
On Oct 1, 2015 12:58 PM, "Chris Barker" [email protected] wrote:

can you use --no-depswithpip install -e` ? or another way to spell it?

If so, only mentioning pip install -e`` is fine. "there should only be one
way to do it"

I'm not going to make a fuss about what the default recommendation should
be - I just wanted the no-deps option to be there so it's easy to find
for others to use if they want.

For my part, I was quite surprised when setup.py develop started
downloading and installing stuff. This doc does currently mention that,
which is great, but it might as well mention how to turn it off, too.

—
Reply to this email directly or view it on GitHub
#176 (comment)
.

[ChrisBarker-NOAA]

great, thanks!

[xavfernandez]

for #1, I think we should only be recommending pip install -e. currently, we mention both. we should change that I think.

I think the same 👍

[qwcode]

I'll post another PR later tonight

well, probably tomorrow, but I won't let it drop : )

[qwcode]

ok, see #177

[qwcode]

closing this issue due to merging #177
if anything still looks unclear, let me know.