-
Notifications
You must be signed in to change notification settings - Fork 69
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
Comments
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. |
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! |
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 :) |
Thanks for the heads up nevertheless! |
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) |
Is that all it was needed? Then I'll close this once all rhe required PRs land. |
Yup, if you merge PR 90 this issue will be automatically closed by github |
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 |
👍 |
I am trying to install pew on a windows machine, using pip. I see that pythonz gets actually installed alongside pew, but apparently neither 'PYTHONZ_ROOT' nor 'HOME' environment variables are set in the environment. |
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 jython, it could in theory work... But the check for jvm availability will fail due to it relying on unix like commandsSent from mobile. Please excuse my brevity. |
Hi Berdario, Actually I need only pew functionality for my current project, how can I Il giorno mer 23 set 2015 alle ore 18:01 berdario notifications@github.com
|
pip install --upgrade pew==0.1.15 Sorry for this, I'd have fixed it last Thursday already, but life intervenedSent from mobile. Please excuse my brevity. |
Thanks a lot.
|
Tried your solution, Again, thank you very much for your prompt response. After your (future) fix, do you suggest I should update to the very last BR On Wed, Sep 23, 2015 at 6:12 PM, berdario notifications@github.com wrote:
|
@berdario sorry I haven't looked at this yet, will do ASAP :-S |
Hi Berdario,
In my environment WORKON_ROOT references a global directory, not $HOME/virtualenvs. BR |
@massimov Please open an issue on my project rather than continuing the discussion here Anyhow, regarding your 2 questions: 1- have a look at the |
I won't be supporting this, please see the reasoning here: #110 (comment) |
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 thePYTHONZ_ROOT
to get the path for patches, shell scripts, etc. (theMANIFEST.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
insubprocess.call
for example)Sorry if this is a sort of brain-dump and not properly structured.
The text was updated successfully, but these errors were encountered: