[Scons-dev] pip install scons

[anatoly techtonik]

On Mon, Mar 28, 2016 at 2:40 AM, Jason Kenny <dragon512 at live.com> wrote:
> I think when this came up before there was a desire for three method.
>
>
>
> 1)      Pip install as a primary method. Allow people to depend on it.

Do you mean `pip install scons` to make scons available in system PATH?
That should be documented, because it is system dependent. On Linux it
probably works out of the box, on Windows it didn't work previously, but now
I see that my SCripts directory is added to PATH for Python 2.7.11

> 2)      RPM, MSI… cases for people that cannot use pip for firewall reasons

MSI? Maybe https://github.com/chocolatey/choco/wiki? It is interesting, what
is the rule of thumb here? Should system-dependent package take priority?
Or should `pip install` win? On Windows Python 2.7.11 Scripts dir is pushed
first to PATH, so it takes priority.

Comparing to others tools, it looks like other tools append their PATHs, so
older Go version will still be found first if two are installed. So the
recommendation could be to uninstall all previous scons versions, or just
describe what happens, so people were aware how to fix their PATHs.

> 3)      Scons local for cases in which people want to install Scons in a
> more system independent way, such as checking source in internal source
> control, so it just works with need to install on system.
>
>
>
> Supporting 1) correctly allow 2) to work as a side effect of different
> package outputs as I understand.
>
> I think 3) is needed very much.

I'd say that's the primary usecase now. It would be also nice to be able
to copy scons using a revision reference in repository.

> I am not sure we have a need to support more than on install directly. I
> will defer if someone feels this needs to support, however every case I have
> seen installing one version of SCons is enough. I only ever used more than
> on version of SCons at a time to help me test stuff in Parts. I could easily
> have done this with virtual env as well.

Yes. virtualenv was born later exactly for this purpose.