Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pythonz without pythonz-install? (or silent pythonz-install) #73

Closed
berdario opened this issue Dec 25, 2014 · 19 comments
Closed

Pythonz without pythonz-install? (or silent pythonz-install) #73

berdario opened this issue Dec 25, 2014 · 19 comments

Comments

@berdario
Copy link
Contributor

Hi, I'd like to drive pythonz from another program (specifically, I was thinking of adding pythonz as a dependency of pew).

For this I tried to install pythonz with the setup.py, and apparently it can work even without running the pythonz-install step (you have to workaround some errors, but it's doable).

I'd prefer if there was no pythonz-install step altogether, it should be relatively easy to adapt it:

just use the INSTALLER_ROOT ( os.path.dirname(os.path.abspath(__file__)) works just fine even inside a setuptools-installed source code), instead of the PYTHONZ_ROOT to get the path for patches, shell scripts, etc. (the MANIFEST.in apparently already ships the needed ).

The update command then wouldn't obviously relied upon anymore (but as long as it can be securely downloaded, a file that specifies the new versions and the needed patches could still be downloaded into PYTHONZ_ROOT, but this is an even bigger change).

Failing this, it'd be nice to at least be able to run a silent installation (without having to muck with the stdout). The installation message asks the user to load the supplied bashrc, but I'm also not sure: it seems mostly to be useful wrappers for completion and the like, but I don't know if by avoiding to use them I might stumble into other problems.

It'd also be useful to have it available on Pypi: Pythonbrew is already there. (This should be another issue, and I could do it myself, but it's probably best to discuss this in advance as well)

I don't know the history of Pythonbrew/Pythonz, so I'm not sure about the policy that you have about such changes. I had a look at the codebase, and apparently there're things kept only for compatibility with older python versions (as the host interpreter for pythonz, I mean), and since what I'm proposing might be controversial I haven't prepared any PR nor tweaked any line of code before opening this issue. (I'd also like to get rid of the code that uses shell=True in subprocess.call for example)

Sorry if this is a sort of brain-dump and not properly structured.

@saghul
Copy link
Owner

saghul commented Dec 27, 2014

I quickly read through your comment, and yeah, for automation purposes it might be worth doing. I guess it basically boils down to generalizing this code: https://github.com/saghul/pythonz/blob/master/pythonz/__init__.py#L23-L44 and making sure all paths are ok. Feel free to open a PR as soon as you have some code so we can see it evolve.

As for having it on PyPI, I'll have a look at doing it for the next release.

@saghul
Copy link
Owner

saghul commented Jun 11, 2015

Sorry, this one fell through the cracks :-S I don't have much time for it, but if you submit a PR with the required changes (if any!) I can make a release on PyPI. Thanks!

@berdario
Copy link
Contributor Author

Don't worry, I have been really busy as well, and I have several patches for my project on the pipeline before tackling this PR. I still want to get this done, just people shouldn't have high expectations of me getting this done very soon :)

@saghul
Copy link
Owner

saghul commented Jun 11, 2015

Thanks for the heads up nevertheless!

@berdario
Copy link
Contributor Author

I just released a new version of pew, that integrates pythonz (with the changes from the 3 PR I opened):

https://pypi.python.org/pypi/pew

If you want to try it out.

(it's nothing special, but my hope is that by having the functionality of installing a new python version AND easily creating a virtualenv in the same tool will make it effortless for people to start adopting newer Python versions)

@saghul
Copy link
Owner

saghul commented Sep 17, 2015

Is that all it was needed? Then I'll close this once all rhe required PRs land.

@berdario
Copy link
Contributor Author

Yup, if you merge PR 90 this issue will be automatically closed by github

@berdario
Copy link
Contributor Author

Forgot to mention, after you merge the other PRs, it'd be good if you made a release on pypi

For the time being, just to try things out on my side, I uploaded a shallow fork on pypi:

https://pypi.python.org/pypi/pythonz-bd

I'll drop it as soon as there's an official release on pypi

yesterday I had a look at this guide (since it was quite a while since I registered a new project on pypi):

http://peterdowns.com/posts/first-time-with-pypi.html

And I suggest if, if for no other reason that it tells you how to try things on the testpypi test server
(When first packaging pew, I've done plenty of setuptools mistakes that resulted in spurious versions being uploaded to pypi... so testing things separately on testpypi would've been useful)

@saghul
Copy link
Owner

saghul commented Sep 17, 2015

👍

@massimov
Copy link

I am trying to install pew on a windows machine, using pip.
Everything seems fine during the installation, but as soon as I try to invoke pew from powershell I get errors like these:
File "C:\Python27\lib\site-packages\pythonz\define.py", line 10, in
ROOT = os.environ.get('PYTHONZ_ROOT') or os.path.join(os.environ['HOME'], '.pythonz') if not os.path.abspath(os.path.dirname(file)).startswith(SYSTEMWIDE_PATH) else SYSTEMWIDE_PATH
File "C:\Python27\lib\os.py", line 425, in getitem
return self.data[key.upper()]
KeyError: 'HOME'

I see that pythonz gets actually installed alongside pew, but apparently neither 'PYTHONZ_ROOT' nor 'HOME' environment variables are set in the environment.
Do you suggest that I set those variables manually? If so, which values do you suggest for a windows installation?
Thank you in advance

@berdario
Copy link
Contributor Author

Hi, that's a bug in pew. I need to disable the pythonz integration on Windows, because even with the correct environment variables, and even by avoiding another small problem, pythonz is unsupported on Windows:

For cpython it'd require a working compiler, and every Cpython version requires a different MSVC version, likely old and unsupported (actually, it could download the pre-built one, but maybe that's a job better suited for chocolatey)
For pypy, it doesn't download the windows version (but windows is kind of a second class citizen for pypy)

For jython, it could in theory work... But the check for jvm availability will fail due to it relying on unix like commands

Sent from mobile. Please excuse my brevity.

@massimov
Copy link

Hi Berdario,
thank you very much for your prompt response.

Actually I need only pew functionality for my current project, how can I
reinstall pew without pythonz? can you suggest a workaround?
BR
Massimo Vanetti

Il giorno mer 23 set 2015 alle ore 18:01 berdario notifications@github.com
ha scritto:

Hi, that's a bug in pew. I need to disable the pythonz integration on
Windows, because even with the correct environment variables, and even by
avoiding another small problem, pythonz is unsupported on Windows:

For cpython it'd require a working compiler, and every Cpython version
requires a different MSVC version, likely old and unsupported (actually, it
could download the pre-built one, but maybe that's a job better suited for
chocolatey)
For pypy, it doesn't download the windows version (but windows is kind of
a second class citizen for pypy)
For jython, it could in theory work... But the check for jvm availability

will fail due to it relying on unix like commands

Sent from mobile. Please excuse my brevity.


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

@berdario
Copy link
Contributor Author

pip install --upgrade pew==0.1.15
Should do

Sorry for this, I'd have fixed it last Thursday already, but life intervened

Sent from mobile. Please excuse my brevity.

@massimov
Copy link

Thanks a lot.
Life must have priority.
I will try very soon and let you know the outcome, if you don't mind.
On Sep 23, 2015 6:12 PM, "berdario" notifications@github.com wrote:

pip install --upgrade pew==0.1.15
Should do

Sorry for this, I'd have fixed it last Thursday already, but life

intervened

Sent from mobile. Please excuse my brevity.


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

@massimov
Copy link

Tried your solution,
seems to work fine.

Again, thank you very much for your prompt response.

After your (future) fix, do you suggest I should update to the very last
version?

BR
Massimo Vanetti

On Wed, Sep 23, 2015 at 6:12 PM, berdario notifications@github.com wrote:

pip install --upgrade pew==0.1.15
Should do

Sorry for this, I'd have fixed it last Thursday already, but life
intervened

Sent from mobile. Please excuse my brevity.


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

@saghul
Copy link
Owner

saghul commented Sep 24, 2015

@berdario sorry I haven't looked at this yet, will do ASAP :-S

@massimov
Copy link

Hi Berdario,
having used pew on windows powershell for a few days, I find it very useful.
There are, however, a couple issues I'm finding strange, can you please tell if they are this way by design?

  1. after pew workon (or new etc) the working directory does not change, I have to cd there by hand (after which, everything seems to work as expected).
  2. after pew workon (or new etc) I lose the command history capability (both from powershell and python prompt)

In my environment WORKON_ROOT references a global directory, not $HOME/virtualenvs.

BR
Massimo Vanetti

@berdario
Copy link
Contributor Author

berdario commented Oct 4, 2015

@massimov
I just released pew 0.1.17, and I suggest you to update. Aside from the fix about disabling pythonz on windows, and the new resumable downloads for pythonz, there are 3/4 small bugfixes

Please open an issue on my project rather than continuing the discussion here

Anyhow, regarding your 2 questions:

1- have a look at the mkproject command: it's just new+setproject. If you want to be dropped in a specific directory when activating the env, you can just use the setproject command on an existing virtualenv.
2- Within a new shell inside a virtualenv, I can still have access to some of the last commands used in another session (the same should apply to every shell that saves the history periodically and not when it terminates). I'm not sure about powershell, but at least a few years ago there was no builtin history retention among sessions. For Python, I assume that you're talking about the history that is now automatically enabled since Python3.4 ... I'm not sure why it's not reused inside a virtualenv. I assume it might be due to some environment variable setting. Open an issue with some details if you want to discuss it.

@saghul
Copy link
Owner

saghul commented Feb 12, 2016

I won't be supporting this, please see the reasoning here: #110 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants