pipsi 0.9 (new formula)

[zbeekman]

pip script installer: install Python scripts with pip to their own
virtualenv to prevent cross contamination and to sandbox them

A note on the test do block. Currently, pipsi provides 4 commands:

• install
• list
• uninstall
• upgrade

The only one of these that seems suitable for a test do block is potentially the list command, although even this will be potentially uninformative. Any other command will have undesired and un-requested effects on the user's system. Unfortunately, for the time being, the list command crashes when nothing has been installed yet. I made the upstream aware of this in mitsuhiko/pipsi#66 so, until this issue is resolved, the only tests I can seem to think of are simple --help or --version tests. Even when list comes online when nothing is installed, this doesn't seem to be more rigorous than --version or --help.

[zbeekman]

@UniqMartin FYI, it looks like the travis test failed due to brew audit --online not being able to connect to the Github API. I suspect if you re-run it it will pass.

[DomT4]

Is there any way to disable the self-update feature? That sort of thing doesn't really play nice with package management:

How do I upgrade pipsi? With 0.5 and later just do this:
pipsi upgrade pipsi

[zbeekman]

Is there any way to disable the self-update feature? That sort of thing doesn't really play nice with package management:

Fair point. AFAICT, no there's no way to do that, without explicitly removing the upgrade functionality. The self upgrading was introduced in v0.5 by commit mitsuhiko/pipsi@7442f7c and looking at lines 156 -- 181 it doesn't look like there's much that can be done about this, short of a patch that would disable upgrading anything and everything installed by pipsi.

[UniqMartin]

@zbeekman That seems to be happening more often in recent times, unfortunately. But as long as the default build (on our Jenkins CI) is fine, you can ignore the Travis CI failure. I agree that it is annoying though and gives a false impression in the PR list.

[DomT4]

AFAICT, no there's no way to do that, without explicitly removing the upgrade functionality

It's not necessarily a blocker but ideally we'd file an Issue upstream asking for a way to disable the self-update mechanism impacting the tool itself specifically.

[zbeekman]

It's not necessarily a blocker but ideally we'd file an Issue upstream asking for a way to disable the self-update mechanism impacting the tool itself specifically.

I'll go ahead and do that now: mitsuhiko/pipsi#68

[tdsmith]

This probably needs to resource pip as well.

[tdsmith]

You should be able to install something as a test; $HOME is set to a temporary path during install and test so pipsi shouldn't actually affect a user's system.

[zbeekman]

@tdsmith Thanks for the insight! I'll go ahead and resource pip, and try a test install... I guess pipsi can uninstall software too... so we just need to find a suitable package with minimal dependencies to install and uninstall in test do

[zbeekman]

@tdsmith I have resourced pip and added the test do block. For this, I install pygments and list installed packages, which reports Pygments.

How are things looking now?

[tdsmith]

Mysterious test failure!

[zbeekman]

Mysterious test failure!

I'm flummoxed

[zbeekman]

My best guess is that this has to do with the environment? Maybe I need ENV.std or similar in the test do block?

I'd appreciate any help or insight @tdsmith or @RonnyPfannschmidt or @mitsuhiko can provide.

[RonnyPfannschmidt]

You need the pipsi bin dir and virtualenv folders within the sandbox

[zbeekman]

You need the pipsi bin dir and virtualenv folders within the sandbox

@tdsmith Do you know how to accomplish this? Should I add a ENV.std to the top of the test do block?

[tdsmith]

I think both of those things should be relative to $HOME so they already are within the sandbox.

[DomT4]

Local readout is:

==> /usr/local/Cellar/pipsi/0.9/bin/pipsi install pygments
New python executable in /private/tmp/pipsi20160221-90138-140pmmh/.local/venvs/pygments/bin/python
Installing setuptools, pip, wheel...done.
Running virtualenv with interpreter /usr/bin/python
You are using pip version 7.0.3, however version 8.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting pygments
  Downloading Pygments-2.1.1-py2.py3-none-any.whl (755kB)
Installing collected packages: pygments
Successfully installed pygments-2.1.1
  Linked script /private/tmp/pipsi20160221-90138-140pmmh/.local/bin/pygmentize
Done.

Structure is more or less:

- testpath
-- .local
  -- bin
    -- pygmentize
  -- venvs
    -- pygments
      -- bin
      -- include
      -- lib

Passes alright though, no strange failures locally.

[zbeekman]

Thanks @DomT4, yes that's what I saw locally too, hence why I pushed it up to the PR.

@RonnyPfannschmidt Any more detailed thoughts? Have you taken a look at the output on Jenkins?

[DomT4]

I doubt it's related but you've added a pip resource that you're not actually installing.

[zbeekman]

Thanks for pointing that out.

On Sun, Feb 21, 2016 at 10:31 AM Dominyk Tiller notifications@github.com
wrote:

I doubt it's related but you've added a pip resource that you're not
actually installing.

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

[zbeekman]

Trying again because I appear to have forgotten to push after resourcing pip

[dunn]

Is this the same failure? http://bot.brew.sh/job/Homebrew%20Pull%20Requests/42318/version=yosemite/testReport/junit/brew-test-bot/yosemite/test_pipsi/

[DomT4]

Looks like it, yeah 😕.

[zbeekman]

Well, if the folks over at the pipsi project don't weigh in soon we may need to close this PR; I'm pretty stuck.

[apjanke]

It's been over a month. Closing this out as infeasible.

If you hear back from upstream or other things change, feel free to resubmit this at the new homebrew/core repo.