Make build error in MacOs #433
Comments
|
Line 45 in 370b073 I assume this is where it fails? Seems like for some reason python fails to find aw_server as a python dependency, maybe something is not working properly with the virtualenv? The exact same thing (make build) in our automated tests passed last time there was a change (5 days ago). |
|
Yes, in that line got the error. I did a test without virtualenv and showed the same message. |
|
Good catch. Can you try running the line "pip install poetry" in the venv and see if this fixes the problem? I tried to reproduce, got the different error ``` |
|
I also got that error the first time I ran the build. After running |
|
On macOS, the install instruction is lacking:
How about a Makefile that involves:
? |
|
Cargo is Rust’s build system and package manager. Rust nightly is necessary for this step:
I'm updating the documentation of installing from source. I'm basing to the travis.yml I found there about Rust and Poetry but I'm still stuck on the error |
|
Not sure what's going wrong here, but a few things:
|
|
if [ -e "aw-core/.git" ]; then Hi I am even facing the same issue, any one please help me in taking it forward. |
|
Try running first |
could install poetry but still the following error persists @snwnst |
|
@iconma You need to run the make command in a virtualenv. |
|
Thanks for the info, But i m stuck here. make --directory=aw-server-rust build SKIP_WEBUI= commented and tried it out But when I type aw-qt it results me below error , help is appreciated Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
To fix the building of aw-server-rust you need to install rust nightly and cargo, most easily done with rustup. What's wrong with aw-qt is clear in the error message with the following
You are missing the sip dependency or have the wrong version of it required by pyqt5, or maybe your virtualenv is not set. |
|
Hi i have fixed venv properly,
|
|
As the error says, you need a nightly version of Rust. |
|
Hi Erik, but I have taken the latest version of it |
While the version is newer, since it does not end with "-nightly" you are not using the nightly version which means that some features are not enabled which are required. |
|
Thanks @johan-bjareholt i am using nightly and lets see how does it go |
|
Got following error.
⠙ Building for production...Starting type checking service... ERROR Failed to compile with 1 errors 3:05:58 PM error in ./src/App.vue?vue&type=template&id=5b53a00e&lang=pug& Module build failed (from ./node_modules/pug-plain-loader/index.js): @ ./src/App.vue?vue&type=template&id=5b53a00e&lang=pug& 1:0-447 1:0-447 Error parsing bundle asset "/Users/shyam/Documents/activitywatch/activitywatch/aw-server-rust/aw-webui/dist/js/chunk-09bc37bc.3dfbcde6.js": no such file No bundles were parsed. Analyzer will show only original module sizes from stats file. Webpack Bundle Analyzer saved report to /Users/shyam/Documents/activitywatch/activitywatch/aw-server-rust/aw-webui/dist/report.html npm ERR! A complete log of this run can be found in: |
|
Hi All , The build is complete successfully could generate the package, but while executing its returning below error. Contents of ./dist
|
|
It's the same error message as above and if I understood things correctly then you had some virtualenv issue? What the error message says is pretty much that aw-qt fails to find correct dependencies on the following line: |
|
when trying to install sip 4.19.4 its saying not found. |
|
Since the error earlier says that you need 'sip<4.20,>=4.19.4' you could just as well install 4.19.8 which is available according to the most recent error. But it would be even better if you could figure out why PyQt did not install it in the first place, seems strange that it did not. |
|
installed the 4.19.8 version, but still the result says the same. wonder how to proceed further during build no such errors identified but while executing repeatedly encountering the same error. |
|
|
|
This might actually be a larger issue as I've seen the same error appear in the automatic Travis builds (that run as cronjobs): https://travis-ci.org/github/ActivityWatch/activitywatch/builds/703142861 I managed to reproduce in my local (Linux) environment by running Still unsure how this appeared all of a sudden, but there's a PR with a fix here: ActivityWatch/aw-qt#60 |
|
@ErikBjare the commit actually broke the build for me on Linux. The logs said it couldn't find the sip version 4.19.8 and that only (5.0.0 + were available), I think due to the other dependencies. I fixed it by deleting the sip line and instead adding: Python="^3.6" |
|
The problem with that solution, iirc, is Your installation probably fails because you use Python 3.8 or newer (for which sip<5.0 isn't available). It's unfortunate that we've been caught in this PyQt5/PyInstaller mess, but I haven't gotten around to finding a fix for it yet. |
|
@ErikBjare I had the same problem - sip wasn't installing with python 3.8. After I read your previous comment and tried with python 3.7, it worked. Can we document that somewhere so that future users running |
* with 3.8 it errors because of sip * ActivityWatch/activitywatch#433
|
Due to wasting a ton of time because of this, I made a PR for the docs... |
|
I'm trying to find the reason for the locked PyQt5, but after searching the issues I'm not finding anything. Maybe we should attempt to get with the times and try and upgrade at some point soon? What do you think @johan-bjareholt? Do you remember what locking the PyQt5 version was about? |
|
@ErikBjare I think it was something with a sub-dependency of newer qt versions not working correctly with pyinstaller. I might be wrong though. |
|
@johan-bjareholt Weird that I can't find any mention of it in issues. I guess we should look at moving to the recently released PyInstaller 4.0 soon (with Python 3.8 support coming in 4.1), might as well take a swing at updating PyQt5 at the same time. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I'm running into the original issue @snwnst referenced today. When running make build, I get the error: I don't think @snwnst ever got his solved? Last comment said he was still stuck. Seems like this thread slowly slipped into tangents! Would be cool to figure out what is happening such that python can't find the aw_server module. I'm in a venv, have tried:
I'm using an M1 Mac, had to use arch86 to install pyqt5, and am generally using arch86 to run most of my commands. Versions: If I do From what @ErikBjare suggested in @ErikBjare suggested in #433 (comment), this seems like it might be part of problem? I don't know how to fix that just yet, any tips appreciated. Pretty sure poetry is creating a new virtual environment for each module. Before each module is installed it says this And you can also see that this is happening in this screenshot of poetry's virtualenv folder.
Nightmare! But at least I've identified that's what's happening. I'm currently looking into how to fix that, any rapid-response suggestions to stop poetry from doing this, or to make sure |
|
@michaeljelly If you're having issues with poetry creating a seperate venv for each module (which it shouldn't if you've already activated a venv, but you never know 🤷), you can disable it using this configuration option: https://python-poetry.org/docs/configuration/#local-configuration Also, a nitpick about your process: don't install poetry in the venv, install it in your system/user Python 3 and then use it with the venv activated. So, to modify your steps:
You might need to wipe your venv (to get rid of the poetry installation within) for your system-poetry to work correctly while it's active. |
|
Thanks so much for the rapid response! Here's my Also I found the poetry config and have changed that so it doesn't create a separate venv. Config is now: My "process" was to try everything haha! Just did that, and finding that I still can't get access to the aw_server module.
I have also tested installing with the poetry config experimental.new-installer = false, as well as true. When it's false, it doesn't create a new environment for every submodule, when it's true it does (or at least tells me about it)! I have also tested creating a venv called Will continue digging on the internet for why python is not able to find aw_server. Strange. Could somehow be an M1 mac problem? What made you say earlier about the which python/python3 paths needing to be the same? |
|
On macOS, Contrast that to modern Linux distros, where So, sanity check: Is your output from You could also just try and comment out the particular Makefile line (or change it to We used to be explicit about using |
|
Possible weirdness found on running I wouldn't expect my python version in Poetry and Virtualenv to be different. Would you? Could be related to this python-poetry/poetry#3508 Going to try uninstalling and reinstalling poetry. Think I originally installed it via cURL :/ |
|
If I do which python and which python 3 I get: So they aren't the same, but python -V and python3 -V are the same. Will try changing the makefile to say python3! |
They are the same. One of them is simply a symlink to the other. |
That looks possible... |
|
Uninstalled poetry via curl, reinstalled it via pip3 install poetry, which meant I had the same python version between poetry and the virtualenv (when I ran poetry debug). AND I added a 3 to the Makefile python command (i.e. and it seems to have worked!! So future humans:
Hopefully if you do these things you don't run into any of these problems! Thanks for your help @ErikBjare ! Maybe we should add the 3 to the Makefile? What do you think Erik? |
|
@michaeljelly Nice! Yes, please make a PR to the repo :) |
May have been what fixed build issue on M1 mac/with poetry ActivityWatch#433 (comment)
|
There we go haha, tiny one! |
I am following the instructions of installing from source in MacOs and when i run
make buildgot this error:The text was updated successfully, but these errors were encountered: