Open kloczek opened 3 years ago
Just tested 4.9.1 and pytest is still failing but new way:
After few upgrades I have now other two units failing
Trying to upgrade to just released 4.9.2 found that new usnit started failing
Just tested 4.10.0 and looks like now is failing more units
I've been tryng to add JUPYTER_CONFIG_PATH
env variable pointing to </install/prefix>/etc/jupiter
with created that directory before pytest execution but it mage pytest results even vorse.
IMO it should be possible to test wit that env variable
First unit fails shows whole set of env variables which could be used
Q: what kind of combination of those env variables should I use for mu build and testing methodology? š¤
We're not setting any env variables in CI, we're just running pytest with some coverage-related flags. It seems like the paths themselves are getting thrown off by the PYTHONPATH modifications.
Could you please retest using methodology which I've described on top of this ticket?
That methodology is widely used on packaging software.
Handful of python modules still have some issues with "testing as installed". One of that modules (still) is for example setuptools
https://github.com/pypa/setuptools/issues/2318
Invoking setup.py directly is deprecated by setuptools themselves. I don't think we want to support that going forward.
Invoking setup.py directly is deprecated by setuptools themselves. I don't think we want to support that going forward.
That setuptools
ticket is not about setup.py.
Taht ticket is already opened ~9 months. In mean time I've moved in all my rpm packages to pep517 build procedure which consist from:
python3 -sBm build -w --no-isolation
build
with --no-isolation
I'm using during all processes only locally installed modulesThis issue has nothing to do with use setup.py build
vs. pep517.
Here is updated pytest output against latest 4.10.0:
Gentle ping .. Just tested 5.1.2
Just FTR there are new units failing
FAILED jupyter_core/tests/test_command.py::test_paths_debug - AssertionError: assert 'JUPYTER_CONFIG_DIR is not set' in 'JUPYTER_PLATFORM_DIRS is set to a false value, or is not set, so we use hardcoded legacy paths for platform-specific ...ter\n...
FAILED jupyter_core/tests/test_paths.py::test_config_dir - AssertionError: assert '/home/tklocz...4/etc/jupyter' == '/home/tkloczko/.jupyter'
FAILED jupyter_core/tests/test_paths.py::test_config_dir_linux - AssertionError: assert '/home/tklocz...4/etc/jupyter' == '/home/tklocz...onfig/jupyter'
FAILED jupyter_core/tests/test_paths.py::test_data_dir_linux_legacy - AssertionError: assert '/home/tklocz...share/jupyter' == '/home/tklocz...share/jupyter'
FAILED jupyter_core/tests/test_paths.py::test_data_dir_linux - AssertionError: assert '/home/tklocz...share/jupyter' == '/home/tklocz...share/jupyter'
FAILED jupyter_core/tests/test_paths.py::test_runtime_dir_linux_legacy - AssertionError: assert '/home/tklocz...pyter/runtime' == '/home/tklocz...pyter/runtime'
FAILED jupyter_core/tests/test_paths.py::test_runtime_dir_linux - AssertionError: assert '/home/tklocz...pyter/runtime' == '/home/tklocz...pyter/runtime'
However this ould be as well resoult of the fact that now I'm performing my build on the system which is cut off from public network.
If those new units are failing because lack of accss to public network they should be marked by @pytest.mark.network
o skip those units automatically on passing `-m "not network"' like it is in many other module test suites.
However this ould be as well resoult of the fact that now I'm performing my build on the system which is cut off from public network.
That should have no effect on these tests. It looks to me like at least some of the tests are failing because JUPYTER_CONFIG_DIR and JUPYTER_DATA_DIR are set when running the tests, which is throwing off the expected default values.
I just tested version 5.3.2 on OpenIndiana and I see these three failures (all other tests either pass or skip):
=================================== FAILURES ===================================
_________________________ test_jupyter_path_user_site __________________________
def test_jupyter_path_user_site():
with patch.object(site, "ENABLE_USER_SITE", True):
path = jupyter_path()
# deduplicated expected values
values = list(
dict.fromkeys(
[
jupyter_data_dir(),
os.path.join(site.getuserbase(), "share", "jupyter"),
paths.ENV_JUPYTER_PATH[0],
]
)
)
for p, v in zip(path, values):
> assert p == v
E AssertionError: assert '/usr/local/share/jupyter' == '/usr/share/jupyter'
E - /usr/share/jupyter
E + /usr/local/share/jupyter
E ? ++++++
p = '/usr/local/share/jupyter'
path = ['/home/marcel/.local/share/jupyter', '/usr/local/share/jupyter', '/usr/share/jupyter']
v = '/usr/share/jupyter'
values = ['/home/marcel/.local/share/jupyter', '/usr/share/jupyter']
tests/test_paths.py:300: AssertionError
________________________ test_jupyter_path_no_user_site ________________________
def test_jupyter_path_no_user_site():
with patch.object(site, "ENABLE_USER_SITE", False):
path = jupyter_path()
assert path[0] == jupyter_data_dir()
> assert path[1] == paths.ENV_JUPYTER_PATH[0]
E AssertionError: assert '/usr/local/share/jupyter' == '/usr/share/jupyter'
E - /usr/share/jupyter
E + /usr/local/share/jupyter
E ? ++++++
path = ['/home/marcel/.local/share/jupyter', '/usr/local/share/jupyter', '/usr/share/jupyter']
tests/test_paths.py:307: AssertionError
_________________________ test_jupyter_path_prefer_env _________________________
def test_jupyter_path_prefer_env():
with prefer_env:
path = jupyter_path()
> assert path[0] == paths.ENV_JUPYTER_PATH[0]
E AssertionError: assert '/home/marcel...share/jupyter' == '/usr/share/jupyter'
E - /usr/share/jupyter
E + /home/marcel/.local/share/jupyter
path = ['/home/marcel/.local/share/jupyter', '/usr/local/share/jupyter', '/usr/share/jupyter']
tests/test_paths.py:313: AssertionError
Testing with 5.4.0 shows the same test failures as with 5.3.2.
Please try #375 and report back there. Thanks!
It is a bit better however still some units are failing
@kloczek thanks for your report - can you suggest a path forward here? Do you think there a common cause to these errors or does it make more sense to open separate issues for the problems you're running into here, and tackle them one at a time?
Just tested 5.5.1 and this time I've looked a git closer. Looks like jupyter_core
and test suite are trying to use pip
.
jupyter_core/troubleshoot.py: env["pip"] = subs([sys.executable, "-m", "pip", "list"])
jupyter_core/troubleshoot.py: if environment_data["pip"]:
jupyter_core/troubleshoot.py: print("\npip list:")
jupyter_core/troubleshoot.py: for package in environment_data["pip"].split("\n"):
tests/test_troubleshoot.py: assert "pip list" in out
Is it really necessary to use pip list
? š¤
Hmmm, not sure I follow. The code you're pointing to only runs if the system has a working pip
, and the test_troubleshoot.py
is not among the failures your reported.
Just normal build, install and test cycle used on building package from non-root: