-
Notifications
You must be signed in to change notification settings - Fork 337
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
Installer updates #662
Installer updates #662
Conversation
-using vendor.distlib instead - new version now incorporates patch previously relied on -see https://bitbucket.org/pypa/distlib/commits/bff28df
-removed hacky ScriptMaker code in install.py
Note also that this PR supersedes #625, although I'm interested in incorporating parts of that into separate PRs (notably, automated pip uploads). I'm also interested in Appveyor, which also belongs in a separate PR (and there is one - #339 - which should be compared with what's available from #625 and potentially combined). |
Will test this today. |
I just gave this a quick run to test the pip installation. The behavior does not match INSTALL.md.
I did the following to install rez through pip:
Now Rez executables still work inside resolved shells though: This should not work, should it? btw. please let me know if you prefer this to be comments in the diff section i can also move it there. |
Also there seems to be an issue with paths containing ~. As our deployment setup installs from a tempfolder generated location this can contain ~ if the corresponding user profile has certain properties (like mine does). Still investigating what change exactly causes that issue and if it is something that should be fixed in Rez or in our setup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff! I've added my two cents, from my humble experience with Rez on PyPI.
INSTALL.md
Outdated
]$ pip install rez | ||
``` | ||
|
||
However, this comes with a caveat - _rez command line tools are disabled once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One solution may be to append the parent directory of which("rez")
in the get_syspaths()
method, here. This would also work on Windows.
INSTALL.md
Outdated
Specifically: | ||
|
||
* When within a rez environment (ie after using the `rez-env` command), the rez | ||
command line tools would not be guaranteed to function correctly; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the above method works, then this may be checked off safely.
INSTALL.md
Outdated
* When within a rez environment (ie after using the `rez-env` command), the rez | ||
command line tools would not be guaranteed to function correctly; | ||
* When within a rez environment, other packages' tools (that were also installed | ||
with pip) would remain visible, but would not be guaranteed to work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be addressed using one of the methods you mentioned in #625.
I made a prototype of this a few weeks ago but haven't been testing it in production for more than a few days, and only on Windows. I've updated it to work on Linux just now, you can test it and see if it fits the bill like this:
$ pip install bleeding-rez
$ rez --version
bleeding-rez-2.33.4
$ rez env python --isolated
The environment you'll get is completely void of anything from the parent environment, including any PYTHONPATH or site-packages. Now, this is so barebones, that it also excludes rez
itself from PATH. So if you wanted it there, you could add it here, where bash
and lsb_release
are explicitly added as well.
Alternatively, the REZ_ENVIRONMENT
variable takes a JSON-serialised environment to be used in place of the skeleton environment built into the source. Out of the box you're left with a Docker-like environment, with only the shell itself plus your resolve.
When you enter a rez environment, the rez packages in the resolve configure | ||
that environment as they see fit. For example, it is not uncommon for a python | ||
package to append to PYTHONPATH. Environment variables such as PYTHONPATH | ||
affect the behaviour of tools, including rez itself, and this can cause it to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would possibly be addressed by the above as well.
to avoid this problem. Specifically: | ||
|
||
* Rez is installed into a virtualenv so that it operates standalone; | ||
* The rez tools are shebanged with `python -E`, in order to protect them from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the --isolated
method works, the python -E
is embedded into Rez, which means we could skip this particular step.
* Rez is installed into a virtualenv so that it operates standalone; | ||
* The rez tools are shebanged with `python -E`, in order to protect them from | ||
environment variables that affect python's behaviour; | ||
* The rez tools are stored in their own directory, so that other unrelated tools |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And finally, due to explicit control over the environment, this would also go away. Pof!
Are you referring to the subprocess approach? I considered this, however
the install.py-based installation works without the need for an extra
subproc. With that in mind, it doesn't make sense to support two different
installation methods, when one results in differing behaviour like this.
However, if enough people feel a great need for production-ready pip
installable rez, we could take that approach, _if_ it's isolated to pip
installations only (ie, install.py should continue doing what it currently
does). If contributed, this belongs in a separate PR.
A
…On Sat, Jul 13, 2019 at 7:31 AM Marcus Ottosson ***@***.***> wrote:
***@***.**** commented on this pull request.
Great stuff! I've added my two cents, from my humble experience with Rez
on PyPI.
------------------------------
In INSTALL.md
<#662 (comment)>:
> +```
+
+Do _not_ move the installation - re-install to a new location if you want to
+change the install path. If you want to install rez for multiple operating
+systems, perform separate installs for each of those systems.
+
+
+# Installation Via Pip
+
+It is possible to install rez with pip, like so:
+
+```
+]$ pip install rez
+```
+
+However, this comes with a caveat - _rez command line tools are disabled once
One solution may be to append the parent directory of which("rez") in the
get_syspaths() method, here
<https://github.com/nerdvegas/rez/blob/installer-updates/src/rezplugins/shell/sh.py#L36>.
This would also work on Windows.
------------------------------
In INSTALL.md
<#662 (comment)>:
> +inside a rez environment (ie after using the `rez-env` command)_. The reasons
+are given in the next section.
+
+Rez installation via pip is not considered production ready. However, if all you
+want is the rez API, and you don't need its tools to be available within rez
+environments, then you can install with pip.
+
+
+# Why Not Pip For Production?
+
+Rez is not a normal python package. Although it can successfully be installed
+using standard mechanisms such as pip, this comes with a number of caveats.
+Specifically:
+
+* When within a rez environment (ie after using the `rez-env` command), the rez
+ command line tools would not be guaranteed to function correctly;
If the above method works, then this may be checked off safely.
------------------------------
In INSTALL.md
<#662 (comment)>:
> +
+Rez installation via pip is not considered production ready. However, if all you
+want is the rez API, and you don't need its tools to be available within rez
+environments, then you can install with pip.
+
+
+# Why Not Pip For Production?
+
+Rez is not a normal python package. Although it can successfully be installed
+using standard mechanisms such as pip, this comes with a number of caveats.
+Specifically:
+
+* When within a rez environment (ie after using the `rez-env` command), the rez
+ command line tools would not be guaranteed to function correctly;
+* When within a rez environment, other packages' tools (that were also installed
+ with pip) would remain visible, but would not be guaranteed to work.
This may be addressed using one of the methods you mentioned in #625
<#625>.
I made a prototype of this a few weeks ago but haven't been testing it in
production for more than a few days, and only on Windows. I've updated it
to work on Linux just now, you can test it and see if it fits the bill like
this:
$ pip install bleeding-rez
$ rez --version
bleeding-rez-2.33.4
$ rez env python --isolated
The environment you'll get is completely void of anything from the parent
environment, including any PYTHONPATH or site-packages. Now, this is so
barebones, that it also excludes rez itself from PATH. So if you wanted
it there, you could add it here
<https://github.com/mottosso/bleeding-rez/blob/d99c7baf65dd4b82ab72e80961c0d77aaefa36be/src/rez/cli/_main.py#L152-L157>,
where bash and lsb_release are explicitly added as well.
Alternatively, the REZ_ENVIRONMENT variable takes a JSON-serialised
environment to be used in place of the skeleton environment built into the
source. Out of the box you're left with a Docker-like environment, with
only the shell itself plus your resolve.
------------------------------
In INSTALL.md
<#662 (comment)>:
> +
+# Why Not Pip For Production?
+
+Rez is not a normal python package. Although it can successfully be installed
+using standard mechanisms such as pip, this comes with a number of caveats.
+Specifically:
+
+* When within a rez environment (ie after using the `rez-env` command), the rez
+ command line tools would not be guaranteed to function correctly;
+* When within a rez environment, other packages' tools (that were also installed
+ with pip) would remain visible, but would not be guaranteed to work.
+
+When you enter a rez environment, the rez packages in the resolve configure
+that environment as they see fit. For example, it is not uncommon for a python
+package to append to PYTHONPATH. Environment variables such as PYTHONPATH
+affect the behaviour of tools, including rez itself, and this can cause it to
This would possible be addressed by the above as well.
------------------------------
In INSTALL.md
<#662 (comment)>:
> +* When within a rez environment (ie after using the `rez-env` command), the rez
+ command line tools would not be guaranteed to function correctly;
+* When within a rez environment, other packages' tools (that were also installed
+ with pip) would remain visible, but would not be guaranteed to work.
+
+When you enter a rez environment, the rez packages in the resolve configure
+that environment as they see fit. For example, it is not uncommon for a python
+package to append to PYTHONPATH. Environment variables such as PYTHONPATH
+affect the behaviour of tools, including rez itself, and this can cause it to
+crash or behave abnormally.
+
+When you use the `install.py` script to install rez, some extra steps are taken
+to avoid this problem. Specifically:
+
+* Rez is installed into a virtualenv so that it operates standalone;
+* The rez tools are shebanged with `python -E`, in order to protect them from
If the --isolated method works, the python -E is embedded into Rez, which
means we could skip this particular step.
------------------------------
In INSTALL.md
<#662 (comment)>:
> +* When within a rez environment, other packages' tools (that were also installed
+ with pip) would remain visible, but would not be guaranteed to work.
+
+When you enter a rez environment, the rez packages in the resolve configure
+that environment as they see fit. For example, it is not uncommon for a python
+package to append to PYTHONPATH. Environment variables such as PYTHONPATH
+affect the behaviour of tools, including rez itself, and this can cause it to
+crash or behave abnormally.
+
+When you use the `install.py` script to install rez, some extra steps are taken
+to avoid this problem. Specifically:
+
+* Rez is installed into a virtualenv so that it operates standalone;
+* The rez tools are shebanged with `python -E`, in order to protect them from
+ environment variables that affect python's behaviour;
+* The rez tools are stored in their own directory, so that other unrelated tools
And finally, due to explicit control over the environment, this would also
go away. Pof!
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#662>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSQD7UKCVYYSAZ2DEOLP7DZ45ANCNFSM4ICDSWPA>
.
|
Ah, it may be that the tool disabling only works in a virtualenv-based pip
installation.
Come to think of it, yeah there's no reliable way to remove visibility of
rez tools without taking out a bunch of other stuff as well. I'll update
the docs in this PR.
…On Fri, Jul 12, 2019 at 7:10 PM Thorsten Kaufmann ***@***.***> wrote:
I just gave this a quick run to test the pip installation. The behavior
does not match INSTALL.md.
However, this comes with a caveat - rez command line tools are disabled
once inside a rez environment (ie after using the rez-env command). The
reasons are given in the next section.
I did the following to install rez through pip:
python setup.py bdist_wheel
pip install rez-2.36.0-py2-none-any.whl
Now Rez executables still work inside resolved shells though:
[image: image]
<https://user-images.githubusercontent.com/243828/61116860-921d8000-a495-11e9-95ba-176b232f70b7.png>
This should not work, should it?
btw. please let me know if you prefer this to be comments in the diff
section i can also move it there.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#662>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSSPFL25J6MKR3GBZTLP7BDATANCNFSM4ICDSWPA>
.
|
install.py
Outdated
_, pip_executable = get_venv_executable(dest_dir, "pip") | ||
|
||
# build wheel | ||
run_command([py_executable, "setup.py", "bdist_wheel"]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can simplify and solidify this by doing:
run_command([py_executable, "-m", "pip", "install", "."])
- Using
py_executable -m pip
you don't need to take care of finding pip. Python will do it for us. pip install .
will build the wheel for you and install it for you. It is a little cleaner and a preferred approach from what I know. The other benefit is that you don't have to look for the wheel in thedist
directory which could have some development stuff in there is not cleaned-up before running theinstall.py
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, changes coming
@@ -13,11 +13,20 @@ | |||
sys.exit(1) | |||
|
|||
|
|||
if sys.version_info < (2, 6): | |||
print("install failed - requires python v2.6 or greater", file=sys.stderr) | |||
if sys.version_info < (2, 7): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we are there, we should also check for python 3. And we should also set the python_requires
argument in the setup
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A py3 port is coming soon (another dev is working on it) so I think I'll leave this for now.
src/rez/cli/_entry_points.py
Outdated
@scriptname("rez-build") | ||
def run_rez_bind(): | ||
from rez.cli._main import run | ||
return run("bind") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you copy/pasted a little too fast 😛 It should be build
and the function name should also contain build
as right now it override the bind. Same for rez-config
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the catch, fixes coming
Yep, tool disabling only works when installing with What do you think? |
INSTALL.md
Outdated
@@ -1,3 +1,85 @@ | |||
# Installation | |||
|
|||
See https://github.com/nerdvegas/rez/wiki/Getting-Started#installation | |||
|
|||
|
|||
First, install Rez. Download the source, and, from the source directory, run: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Philosophical question (sorry in advance): Should we move this doc in the https://github.com/nerdvegas/rez/wiki/Getting-Started#installation doc? I'm also wondering if we should add a mention about how to install in the README as it's usually a common practice to do so.
Or we want to tackle that into a separate subject and wait for your roadmap before deciding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes to both, will make those changes.
Please ignore this one, i found the issue and it is not within Rez. Sorry for that. |
-warning msg on cli tools added for non-pip installation -simplified setup.py
|
||
@scriptname("rez") | ||
def run_rez(): | ||
check_production_install() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if you had a reason to not move that into the rez.cli._main.run
. I have no problem if we do the check here. The only reason why I was mentioning rez.cli._main
is because that would allow us to remove some duplication and have the check more centralized. Maybe you see a future where one command would not need the check?
The reason really is just to get this code into the callstack as early as
possible. The more rez code we import in a non-production-safe install, the
more chance something goes wrong before the warning is printed.
A
…On Tue, Jul 16, 2019 at 12:20 PM Jean-Christophe Morin < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/rez/cli/_entry_points.py
<#662 (comment)>:
> + filepath = os.path.join(path, ".rez_production_install")
+
+ if not os.path.exists(filepath):
+ sys.stderr.write(
+ "Pip-based rez installation detected. Please be aware that rez command "
+ "line tools are not guaranteed to function correctly in this case. See "
+ "https://github.com/nerdvegas/rez/wiki/Installation#why-not-pip-for-production "
+ " for futher details.\n"
+ )
+
+
+### Entry points
+
***@***.***("rez")
+def run_rez():
+ check_production_install()
I'm wondering if you had a reason to not move that into the
rez.cli._main.run. I have no problem if we do the check here. The only
reason why I was mentioning rez.cli._main is because that would allow us
to remove some duplication and have the check more centralized. Maybe you
see a future where one command would not need the check?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#662>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSRNEU6IHKTL3ZUHZ2LP7UWAFANCNFSM4ICDSWPA>
.
|
It makes a lot of sense. I'm also wondering if we should write some tests to make sure it behaves as we want and that it stays like this in the future. With potentially all the cases we found in the last couple of weeks. What do you think? Not too sure how we would go on testing that though. |
Yeah perhaps, but let's leave it on ice for the moment. There's a lot to
do, we'll see if any problems arise.
A
…On Wed, Jul 17, 2019 at 10:09 AM JeanChristopheMorinRodeoFX < ***@***.***> wrote:
It makes a lot of sense.
I'm also wondering if we should write some tests to make sure it behaves
as we want and that it stays like this in the future. With potentially all
the cases we found in the last couple of weeks.
What do you think? Not too sure how we would go on testing that though.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#662>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMOUSTD7AMZN662QJ6IZU3P7ZPNDANCNFSM4ICDSWPA>
.
|
Can anyone confirm that this has been tested on Windows? I think we're ready to merge if so. |
I tried it and it broke for me in various places. I am not sure if this is our setup though. Will do a vanilla install and report later today. Sorry for the delay. Too many things going on at once he. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After setting things up properly and deploying using our deployment setup everything seems to be working fine as far as i can tell. Sorry again for the delays.
Now the setup.py is able to make binary scripts by itself and install them as data_files under rez production dir 'bin/rez' (or 'Scripts/rez' on Windows). However, console_scripts 'rez' is conflicting with the rez production dir 'rez'. Since the previous install.py already removing those scripts before doing the *patch*, console_scripts should be ignored in new setup.py. See AcademySoftwareFoundation#625 and AcademySoftwareFoundation#662 for reason why adding console_scripts in the first place.
This PR updates the current installer. Changes include:
It would be great if others could test this, especially Windows users.