Folders (containing source code files) that are imported into Grey Hack are not deleted after auto compilation process has been completed [Potential Bug] about greybel-js HOT 15 CLOSED

I have finished implementing the said flag as well as the functionality backing it up.

Thanks. I've reviewed your PR and left one comment regarding the logic of deleting the folders. Once you've resolved that I am happy to merge the PR.

Thank you for reviewing my PR, with regards to the change that you proposed, I might have certain questions about it which I have posted in my responses to your comment on my PR, I would appreciate it if you could take a look at them and answer them as soon as possible, thank you in advance.

from greybel-js.

Since this issue has been resolved, I will close it. Thanks again for helping to resolve it.

from greybel-js.

Hey thanks for reporting. This is a known issue which I don't really plan to fix for now since it kinda means unnecessary added complexity.

Let's take your example for instance. So let's say the helpers folder already existed on the machine then you probably don't want it to be actually removed. Therefore this means I would need to keep track if a folder already exists ahead of time or not. Generally it's not a real issue to add this whole logic but it would add further latency on the whole transaction process between greybel and game since for each folder I would need to check if it existed pre import. Thus I am not sure if it is worth the effort since it may increase latency too much just for the sake of deleting left over folders.

Overall I don't think that the left over folders cause such a headache. I think for most users of this feature it's more about not leaving any source files on the in-game computer.

Anyway I can take a look into how much the check would add on top of the current latency and maybe give a bit more feedback in this thread. But saying that I would keep it rather low prio for now.

from greybel-js.

Hey thanks for reporting. This is a known issue which I don't really plan to fix for now since it kinda means unnecessary added complexity.

Let's take your example for instance. So let's say the helpers folder already existed on the machine then you probably don't want it to be actually removed. Therefore this means I would need to keep track if a folder already exists ahead of time or not. Generally it's not a real issue to add this whole logic but it would add further latency on the whole transaction process between greybel and game since for each folder I would need to check if it existed pre import. Thus I am not sure if it is worth the effort since it may increase latency too much just for the sake of deleting left over folders.

Overall I don't think that the left over folders cause such a headache. I think for most users of this feature it's more about not leaving any source files on the in-game computer.

Anyway I can take a look into how much the check would add on top of the current latency and maybe give a bit more feedback in this thread. But saying that I would keep it rather low prio for now.

Hi there, thank you for your response and for informing me about this matter.

However, I am not sure about why you made the assumption that if the helpers folder already existed on my GH (Grey Hack) machine then I would not want it to be removed. Shouldn't files and folders be treated the same by the tool instead of being treated differently?

Example 1: Let's say that I have a helpers.src file which already exists on my GH machine, when the auto-compilation process is completed, the helpers.src file will be removed regardless of whether it existed on my GH machine before the auto-compilation process was started or not.

In Example 1, the implicit assumption made (i.e. by you or by the tool) was that the user would be alright with the helpers.src file being removed after the auto-compilation process was completed.

Example 2: Let's say that I have a helpers folder which already exists on my GH machine, when the auto-compilation process is completed, unlike the aforementioned helpers.src file, the helpers folder will not be removed because as you mentioned, you are not sure if the folder should actually be removed or not, so you instead assume that the user does not want the folder removed, however, this assumption is not made for files which I find quite inconsistent and strange.

In Example 2, the implicit assumption made (i.e. by you or by the tool) was that the user would not be alright with the helpers folder being removed after the auto-compilation process was completed.

As you can hopefully see from the 2 aforementioned examples, the assumption made (i.e. by you or by this tool) for files and folders is different, which leads to unnecessary inconsistency (and perhaps even confusion on the part of the user), ideally, the assumptions made for files and folders should be the same (at least as much as possible) so as to increase consistency and minimize the chances of users running into unexpected behaviors when using this tool (which might also improve their perception of the reliability of this tool).

This tool does not seem to take responsibility for preserving files that the user might or might not want to keep on their GH machine (when auto-compiling), so why should it suddenly take responsibility for preserving folders that the user might or might not want to keep on their GH machine (when auto-compiling)?

from greybel-js.

I get your point but what you may forget is that users may do not think about the fact that their already existing folders may get deleted by using greybel for importing and auto-compiling files which may result in frustration since their files get deleted. Therefore I think it is better to be safe than sorry.

However, I am not sure about why you made the assumption that if the helpers folder already existed on my GH (Grey Hack) machine then I would not want it to be removed. Shouldn't files and folders be treated the same by the tool instead of being treated differently?

I don't think that the assumption that if a folder already exists on an in-game computer, it should remain is, in any sense, far-fetched. Also, there is certainly a difference between a file and a folder. If you override a file, you already take that into account; therefore, deleting it after the fact is obviously inevitable. On the other hand, a folder is not like a file. You do not override the folder. You merely add or remove files to or from it.

Example 1: Let's say that I have a helpers.src file which already exists on my GH machine, when the auto-compilation process is completed, the helpers.src file will be removed regardless of whether it existed on my GH machine before the auto-compilation process was started or not.

In Example 1, the implicit assumption made (i.e. by you or by the tool) was that the user would be alright with the helpers.src file being removed after the auto-compilation process was completed.

I think you should be aware that you are essentially overriding a file. Therefore it is save to assume that it gets lost regardless since there is no way that the original file will be recovered.

Example 2: Let's say that I have a helpers folder which already exists on my GH machine, when the auto-compilation process is completed, unlike the aforementioned helpers.src file, the helpers folder will not be removed because as you mentioned, you are not sure if the folder should actually be removed or not, so you instead assume that the user does not want the folder removed, however, this assumption is not made for files which I find quite inconsistent and strange.

In Example 2, the implicit assumption made (i.e. by you or by the tool) was that the user would not be alright with the helpers folder being removed after the auto-compilation process was completed.

A folder cannot be compared to a file. In my opinion if a folder already exists and there are files in the folder which are unrelated to the compilation process that folder should remain.Therefore, I don't really share the opinion that this is inconsistent or strange.

Also please keep in mind the main reason why the folders currently remain is mainly for the sake of simplicity. But in a perfect implementation I would check if there are still files remaining in the folder and depending on that would remove related folders.

As you can hopefully see from the 2 aforementioned examples, the assumption made (i.e. by you or by this tool) for files and folders is different, which leads to unnecessary inconsistency (and perhaps even confusion on the part of the user), ideally, the assumptions made for files and folders should be the same (at least as much as possible) so as to increase consistency and minimize the chances of users running into unexpected behaviors when using this tool (which might also improve their perception of the reliability of this tool).

This tool does not seem to take responsibility for preserving files that the user might or might not want to keep on their GH machine (when auto-compiling), so why should it suddenly take responsibility for preserving folders that the user might or might not want to keep on their GH machine (when auto-compiling)?

I think we have a general disagreement when it comes to the understanding of how a folder and file should be treated since from your definition it should be clearly treated the same. But I think there should be a difference between treating these two things.

Also again, and I may repeat myself, I don't think that remaining folders will lead to huge problems nor any major confusion.

from greybel-js.

Anyway I've gonna ask in the discord for more opinions on this.

from greybel-js.

I get your point but what you may forget is that users may do not think about the fact that their already existing folders may get deleted by using greybel for importing and auto-compiling files which may result in frustration since their files get deleted. Therefore I think it is better to be safe than sorry.

However, I am not sure about why you made the assumption that if the helpers folder already existed on my GH (Grey Hack) machine then I would not want it to be removed. Shouldn't files and folders be treated the same by the tool instead of being treated differently?

I don't think that the assumption that if a folder already exists on an in-game computer, it should remain is, in any sense, far-fetched. Also, there is certainly a difference between a file and a folder. If you override a file, you already take that into account; therefore, deleting it after the fact is obviously inevitable. On the other hand, a folder is not like a file. You do not override the folder. You merely add or remove files to or from it.

Example 1: Let's say that I have a helpers.src file which already exists on my GH machine, when the auto-compilation process is completed, the helpers.src file will be removed regardless of whether it existed on my GH machine before the auto-compilation process was started or not.
In Example 1, the implicit assumption made (i.e. by you or by the tool) was that the user would be alright with the helpers.src file being removed after the auto-compilation process was completed.

I think you should be aware that you are essentially overriding a file. Therefore it is save to assume that it gets lost regardless since there is no way that the original file will be recovered.

Example 2: Let's say that I have a helpers folder which already exists on my GH machine, when the auto-compilation process is completed, unlike the aforementioned helpers.src file, the helpers folder will not be removed because as you mentioned, you are not sure if the folder should actually be removed or not, so you instead assume that the user does not want the folder removed, however, this assumption is not made for files which I find quite inconsistent and strange.
In Example 2, the implicit assumption made (i.e. by you or by the tool) was that the user would not be alright with the helpers folder being removed after the auto-compilation process was completed.

A folder cannot be compared to a file. In my opinion if a folder already exists and there are files in the folder which are unrelated to the compilation process that folder should remain.Therefore, I don't really share the opinion that this is inconsistent or strange.

Also please keep in mind the main reason why the folders currently remain is mainly for the sake of simplicity. But in a perfect implementation I would check if there are still files remaining in the folder and depending on that would remove related folders.

As you can hopefully see from the 2 aforementioned examples, the assumption made (i.e. by you or by this tool) for files and folders is different, which leads to unnecessary inconsistency (and perhaps even confusion on the part of the user), ideally, the assumptions made for files and folders should be the same (at least as much as possible) so as to increase consistency and minimize the chances of users running into unexpected behaviors when using this tool (which might also improve their perception of the reliability of this tool).
This tool does not seem to take responsibility for preserving files that the user might or might not want to keep on their GH machine (when auto-compiling), so why should it suddenly take responsibility for preserving folders that the user might or might not want to keep on their GH machine (when auto-compiling)?

I think we have a general disagreement when it comes to the understanding of how a folder and file should be treated since from your definition it should be clearly treated the same. But I think there should be a difference between treating these two things.

Also again, and I may repeat myself, I don't think that remaining folders will lead to huge problems nor any major confusion.

I see, thank you for your response and for getting the opinions of other users on the Discord server with regards to this issue.

I get your point but what you may forget is that users may do not think about the fact that their already existing folders may get
deleted by using greybel for importing and auto-compiling files which may result in frustration since their files get deleted.
Therefore I think it is better to be safe than sorry.

With regards to the following statement that you made in your response, one suggestion comes to mind, with the said suggestion being that a CLI option (named something like --preserve-folders-after-auto-compile, or it could be given a shorter or more concise name) could be added so that users could specify whether they want the affected folders on their GH machine preserved or removed after the auto-compilation process has been completed. This way, no assumptions would have to be made by you regarding the ambiguous matter of whether a user is alright or not alright with the affected folders being deleted from their GH machine after the auto-compilation process has been completed, the user will also have more flexibility when it comes to deciding whether the affected folders should be preserved or removed from their GH machine after the auto-compilation process has been completed.

from greybel-js.

If you are alright with the suggestion that I mentioned in my previous message, I would be willing to help out with implementing it.

from greybel-js.

Generally I agree with adding an option but I think the default behaviour should be that folders will get preserved especially keeping in mind being backwards compatible.

Therefore I would suggest to add a option such as --auto-compile-purge or maybe just --purge to just forcefully remove every folder regardless of if there are remaining files/folders or not.

If you are alright with the suggestion that I mentioned in my previous message, I would be willing to help out with implementing it.

I've already started yesterday working on implementing the deletion + preservation logic. I can push that branch in a bit and then you could implement the --auto-compile-purge option if you want.

from greybel-js.

Alright I just pushed 3.2.16. Feel free to implement the flag by basing off that branch. It should be a lot easier to implement via that branch since I've extended the agent to allow code execution.

from greybel-js.

Alright I just pushed 3.2.16. Feel free to implement the flag by basing off that branch. It should be a lot easier to implement via that branch since I've extended the agent to allow code execution.

I see, thank you, and sure.

from greybel-js.

I have finished implementing the said flag as well as the functionality backing it up.

from greybel-js.

I have finished implementing the said flag as well as the functionality backing it up.

Thanks. I've reviewed your PR and left one comment regarding the logic of deleting the folders. Once you've resolved that I am happy to merge the PR.

from greybel-js.

Should be available now with 3.2.16 released.

from greybel-js.

I see, thank you.

from greybel-js.