search

ambisonictoolkit / atk-kernels

A set of impulse response files used for convolution-based encoders and decoders
Other
15 stars 3 forks source link

Installation folder name conflict #5

Closed joslloand closed 6 years ago

joslloand commented 8 years ago

The release for kernels comes in a folder with the release number appended and "atk-" prepended. E.g.,

atk-kernels-1.1.0

atk-sc3 expects the kernel folder to just be named

kernels

As a result, dropping the unzipped and un-renamed folder into Platform.userExtensionDir does not result in a working atk-sc3 installation. Here's my reply on the sc-users list to a new user attempting an installation.

The question, then, is what is the best way to resolve? Do we just give atk-sc3 users an instruction to rename the folder as I've done here (follow to my reply at the bottom)?

We'd like atk-sc3 and atk-reaper to both use the same assets to keep everything synchronized.

Related atk-sounds issue: Installation folder name conflict #3

mtmccrea commented 8 years ago

Renaming would be a cumbersome step in an already cumbersome install process ;)

If it's important to have a version number in the folder name (ad opposed to a README file in the directory listing the version, or somesuch..) we can parse the folder names in the appSupp/ATK and look for "kernels" in a folder name, which the PathName class can facilitate fairly easily. We're assuming there wouldn't be any other folders in that directory level with "kernels" in the name.

So, what's the use currently for having the version in the directory name?

joslloand commented 8 years ago

@lossius, how is this currently working with the atk-reaper installation?

lossius commented 8 years ago

If we use releases at GitHub, the zipped folders will always end with the version number.

In atk-reaper I have set up atk-kernels as a subfolder, and I am using shell scripts to prepare the zipped folder for Windows and the Disk Image installer for Mac.

If you want to get rid of the version number at the end, I can think of three approaches to investigate further:

  1. Handcrafting the releases, upload to Dropbox or similar, and use e.g. Bit.ly for download statistics sot hat you can avoid the version number in the unzipped file.
  2. Move all the content of atk-kernels to a new folder in the repository named kernels, and have users copy that holder over, rather than the top level folder (but I can imagining this leading to confusion, misunderstandings and support questions.
  3. Research if there are ways of handcrafting GitHub releases with your own binary files so that you manage to override the default behaviour. If you want to do this, the best is probably to fork atk-kernels, go haywire with tests in the forked repository to try different approaches, and if you find a workflow, delete the fork and start using that workflow with atk-reaper.

For OSX it would also be possible to make a atk-kernels only installer. After all we know exactly where the files need to go within the folder structure on the users computer. We have the structure set up for this already with the OSX install stuff in atk-reaper. I don't know how the installation of atk-kernels for sc3 has to work on Windows.

joslloand commented 8 years ago

Useful thoughts here... I'll go ahead and do an "inline" style reply, @lossius

If we use releases at GitHub, the zipped folders will always end with the version number.

@mtmccrea and I spoke about the version numbering this morning. This would be useful, particularly in an atk-sc3 context. Having a way to track installed kernel versions would simplify troubleshooting, and confirming whether a user has the latest & greatest assets.

In atk-reaper I have set up atk-kernels as a subfolder, and I am using shell scripts to prepare the zipped folder for Windows and the Disk Image installer for Mac.

Hmm... this would mean that atk-reaper and atk-sc3 are not parallel at the moment in terms of assets. (On OSX) atk-sc3 currently expects assets to be found in:

And soon:

We would prefer that having installed either atk-sc3 or atk-reaper, both platforms use the same assets. Otherwise, there is a strong potential that updates of assets for one platform don't propagate across. This will create confusion for users who use both forms of the ATK—something we'd want to avoid. (In the long-term, we'll also use this folder to support the research grade atk-julia.)

If you want to get rid of the version number at the end, I can think of three approaches to investigate further:

  1. Handcrafting the releases, upload to Dropbox or similar, and use e.g. Bit.ly for download statistics sot hat you can avoid the version number in the unzipped file.

Yuck! (I need a little emoji here!) The main yuck-iness is in regards to using something external to GitHub, e.g. Dropbox or GoogleDrive. It would be nice to just have everything happily distributed via the GitHub platform.

What we'll get now, using the current GitHub release form will be:

Actually, this could be our preferred solution. It would mean we'd have the version number on hand for diagnostics. It would also mean a very bad thing in that the current release of atk-sc3 (sc3-plugins 4.7.2) will be broken until the sc3-plugins 4.7.3 release, in a few months. (This bug!)

We could moderate this by including work-around instructions for users. (Probably the easiest would be to ask users to just download the bugfix .sc file from our repo.)

  1. Move all the content of atk-kernels to a new folder in the repository named kernels, and have users copy that holder over, rather than the top level folder (but I can imagining this leading to confusion, misunderstandings and support questions.

Yeah, we want to minimize confusion. So... this probably isn't a good choice.

  1. Research if there are ways of handcrafting GitHub releases with your own binary files so that you manage to override the default behaviour. If you want to do this, the best is probably to fork atk-kernels, go haywire with tests in the forked repository to try different approaches, and if you find a workflow, delete the fork and start using that workflow with atk-reaper.

This could be possible. I've put that on a todo to have a look. We could still include the versioning idea, but not using folder naming. One though would be to use the current folder format:

And then include maybe a text file in the the kernels directory just named [version number]. There may be more elegant solutions, of course.

The thing to be clear about is that the current kernels and sounds release folder naming does break the atk-sc3 installation. Doh!

joslloand commented 8 years ago

Ok, I'm now understanding some possible ways forward, and will try a few things to see how it goes.

Really, this has to do with me not being completely familiar with how releases on GitHub work. The two immediate things that come to mind after a bit of reading:

  1. use the title field for releases
  2. hand package "binaries" for release, as does the SuperCollider project

I'll do a little experiment with the first and see how it goes. The second will definitely "work".

If we are going to go with the discussed option described above, e.g.,

we'll still need a short-term solution for atk-sc3 users. Packaging "by hand" would do the trick for those users, with a brief note clarifying what to do.

lossius commented 8 years ago

I'll have to investigate if I'm abel to load content from a folder that I don't know the full name of in Reaper (where the ver no. varies), but I anyway think that expecting the ver. no. as a tail to the folder name is a bad idea.

I have currently set up the Reaper project so that atk-kernels is a git submodel, and I can automate the creation of installers. This will break if we start assuming that the name of the atk-kernel folder change depending on version. Additional there is a major risk of conflicts, as users may have atk-kernels-v1.0.3 and atk-kernels-v1.0.4 folders sitting next to each other...

IMHO the best solution is to move all the content in atk-kernels to a new subfolder called "atk-kernels", and then we make sure that that folder, rather than the topmost, gets copied to the appropriate location.

If we want to track down what version users have, the best is to do that using the CHANGELOG file by listing changes to versions, implicitly also stating what version is installed.

mtmccrea commented 8 years ago

IMHO the best solution is to move all the content in atk-kernels to a new subfolder called "atk-kernels", and then we make sure that that folder, rather than the topmost, gets copied to the appropriate location.

If we go this route, can we consider the subfolder be named simply "kernels"? (after all it's parent folder is already "ATK"). This would then work with the ATK-sc as-is, and would fix the path discrepancy that currently breaks the kernel loading in ATK-sc (!). The only additional step this adds is that users move a subfolder into the correct place, rather than the topmost folder after unzipping the release. A little annoying but worthwhile to play nice with the current Git workflow.

And adding a changelog seems like a good idea in any case. If we wanted to get fancy we could add a .kernelVersion method to ATK-sc that reads the changelog's first line for the version, or something similar...

joslloand commented 6 years ago

Resolved by creating .zip for release.

I.e., un-versioned....