Update Installs Inside of New Folder In Installation Directory #55
Comments
|
@nicholas-ewing Thanks for trying out Although I don't think this is the cause of the issue, one thing does stand out in your code: The In tufup-example these are defined as (also see e.g. microsoft docs): WIN_PER_USER_DATA_DIR = pathlib.Path(os.getenv('LOCALAPPDATA'))
WIN_PER_USER_PROGRAMS_DIR = WIN_PER_USER_DATA_DIR / 'Programs'Also note that the per-machine path definitions can be removed if you only do per-user installs. |
|
@nicholas-ewing Some questions to help us figure out the cause of the issue:
|
|
@nicholas-ewing Another question: Did you also try to run the |
|
@nicholas-ewing And one more: How is the tufup Specifically, what value do you specify for the This ultimately determines where your files end up. For example: client = Client(..., app_install_dir=settings.INSTALL_DIR, ...) |
dennisvang
added
the
needs more info
|
@nicholas-ewing And yet another question: How exactly do you "run" your app when doing the update? (your step 7.) |
|
Thanks for pointing out that I mixed up the per-user data and program directories. However, after fixing that problem (and I even tried reverting back to see if I could fix it) now I'm facing a new problem, this one is with python-tuf itself not tufup but I can't see any reason why it's happening and maybe you could be of some assistance with this problem as well. The file it is attempting to download (Scheduling-0.2.tar.gz) is listed as a size of 42,860,829 bytes and a size on disk of 42,864,640 bytes. It didn't do this before, and I have changed nothing but the flipped data & program directories in regards to the update files for the application. Also, going to localhost:8000/targets and manually downloading the 0.2 tgz file, it downloads as the correct size. I would like to also add that I chose to name the "temp" directory in your example as "releases" in my use.
Scheduling.spec: (command and file) # -*- mode: python ; coding: utf-8 -*-
block_cipher = None
a = Analysis(
['main.py'],
pathex=[],
binaries=[],
datas=[('assets', 'assets'), ('../releases/repository/metadata/root.json', '.')],
hiddenimports=[],
hookspath=[],
hooksconfig={},
runtime_hooks=[],
excludes=[],
win_no_prefer_redirects=False,
win_private_assemblies=False,
cipher=block_cipher,
noarchive=False,
)
pyz = PYZ(a.pure, a.zipped_data, cipher=block_cipher)
splash = Splash(
'../application_files/intrasect.png',
binaries=a.binaries,
datas=a.datas,
text_pos=None,
text_size=12,
minify_script=True,
always_on_top=True,
)
exe = EXE(
pyz,
a.scripts,
splash,
[],
exclude_binaries=True,
name='Scheduling',
debug=False,
bootloader_ignore_signals=False,
strip=False,
upx=False,
console=False,
disable_windowed_traceback=False,
argv_emulation=False,
target_arch=None,
codesign_identity=None,
entitlements_file=None,
icon=['..\\application_files\\calendar.ico'],
)
coll = COLLECT(
exe,
a.binaries,
a.zipfiles,
a.datas,
splash.binaries,
strip=False,
upx=False,
upx_exclude=[],
name='Scheduling',
)
def update() -> None:
# Create update client
client = Client(
app_name = APP_NAME,
app_install_dir = INSTALL_DIR,
current_version = APP_VERSION,
metadata_dir = METADATA_DIR,
metadata_base_url = METADATA_BASE_URL,
target_dir = TARGET_DIR,
target_base_url = TARGET_BASE_URL,
refresh_required = False
)
if client.check_for_updates():
client.download_and_apply_update(
skip_confirmation=True,
progress_hook = progressHook,
purge_dst_dir = False,
exclude_from_purge = None,
log_file_name = "install.log"
)
Once again, if I forgot something just let me know. I'll let you know if the example works. |
|
I just used your example application in tufup-example and I had the exact same problem. The extracted files are put in a "main" folder within the install directory. I also tried using
Since that didn't work I'll look through the past few commits on my project and see if I missed some change that is causing the error I described in my previous reply. |
|
Looking through the past few commits of my project, nothing had changed with the updater module from the time I made this issue to when I fixed the program and data directory switch. I also considered the possibility that when I copy the config folder into the application folder after it was compiled could be causing the download mismatch error. However, the error still occurred when I didn't bundle the config folder and instead manually copied the config folder to the installation directory. |
|
@nicholas-ewing Thanks for the highly detailed response. I've just gone through the tufup-example cycle twice: once using It turns out that the instructions for step 3 (repo-side) in the tufup-example readme are inconsistent:
Nevertheless, both executabes appear to work as expected. I did notice some empty folders appearing in one case, and a Did you inspect the content of the Could you try running the tufup-example executable from the same location before and after the update, this time not by double clicking, but by running it from a command window? That way you'll be able to inspect the version number in the output. |
|
I will try the tufup-example again, but can you confirm if the tufup CLI command is meant to use |
|
Here is the output from tufup-example (these were bundled using After the install the "main" folder appears in the "my_app" folder, and if I manually overwrite the files in my_app with those in main, it works, but tufup isn't doing this automatically: |
@nicholas-ewing Both can work, as the command just "zips" the content of the specified directory. Upon installation of the update, the content of this archive is then extracted into the So, if you use On my system, both approaches work without issue. |
|
@nicholas-ewing After reading back over your initial description of the issue, I noticed your "step 5":
On second thought, this may be what's going wrong. Please refer to step 1 from the client-side instructions in the tufup-example readme:
Here's how I do it, step-by-step:
If that still does not work I would suggest trying to run the tufup-example from a completely clean slate. That means:
Make sure you haven't skipped any of the above steps. Then follow the exact steps from the readme, using the |
|
I just finished trying both the |
|
@nicholas-ewing Good to hear it works now. :-) Just out of curiosity: Both the script approach and the CLI approach should work. This time round, did you extract the |
dennisvang
added
question
|
A quick test on my home PC with the CLI commands and it looks like it worked fine there, I'll be able to test with my laptop (my main device when I've been working on my project) tomorrow and see if the CLI problem only exists there. I'm still somewhat confused though because I initially (before I created this issue) did testing on my PC (even using |
|
@dennisvang It worked perfectly... I have no idea why it wasn't working and all the sudden it does work after trying the |
|
@nicholas-ewing Thanks again for the update. :-) I'll close the issue now. |
I am doing some tests with tufup on an application and when tufup installs the update from the local server, it works just fine. Only, it installs in a subfolder within the installation directory. So the application can never start because it never actually get overwritten by the new one.
Steps to reproduce the behavior:
Following exact steps from tufup-example, but with my own application.
Log file from after update:
install.log
Code from settings.py file in application:
(Almost an exact match to the example)
Subfolder with the updated app file:
System Info:
If I missed something important just let me know.
The text was updated successfully, but these errors were encountered: