Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes 'dot-' preprocessing fails for dot-directories (#33, Savannah#56727) #70

Merged
merged 4 commits into from
Apr 6, 2024

Conversation

AitorATuin
Copy link
Contributor

@AitorATuin AitorATuin commented May 24, 2020

Fixes http://savannah.gnu.org/bugs/?56727 and #33.

Problem was that when running stow_contents/unstow_contents recursively from
stow_node/unstow_node the information for the source path (without the dot- to
. transformation) was lost.

In the case of stow_contents, each time it's called from stow_node ../ it's prefixed to the source. The solution there is just to keep track of the level of recursion and delete as many dots as levels.

In the case of unstow_contents the solution is just to provide the source from unstow_node.

Problem was that when running stow_contents/unstow_contents recursively from
stow_node/unstow_node the information for the source path (without the dot- to
. transformation) was lost.

In the case of stow_contents the solution is just to remove the leading
dots (..) from the $source path (since the $source path is passed as an argument
to the function)

In the case of unstow_contents the solution is the same as for stow_contents but
the arguments was now passed so I added it to the function.
@coveralls
Copy link

coveralls commented May 24, 2020

Coverage Status

Coverage remained the same at 86.312% when pulling a41118d on AitorATuin:bug-56727 into 9fd3624 on aspiers:master.

@aspiers aspiers changed the title Fixes Bug #56727 Fixes Savannah bug 56727 Sep 16, 2020
@aspiers aspiers added the dotfiles Issues with --dotfiles option label Apr 5, 2021
@aspiers aspiers added this to the Release 2.3.3 milestone Apr 5, 2021
@aspiers aspiers added the bug label Apr 5, 2021
@nabaco
Copy link

nabaco commented Apr 28, 2021

Hi, I have tested this locally and can confirm that is solves the issue.
Fixes #33

@aspiers
Copy link
Owner

aspiers commented Apr 30, 2021

Thanks a lot for the testing, I'll definitely take that into account!

@AitorATuin
Copy link
Contributor Author

@aspiers please, tell me if I you want me to squash the commits or change something. Thanks.

@aspiers aspiers changed the title Fixes Savannah bug 56727 Fixes 'dot-' preprocessing fails for dot-directories (Savannah#56727) May 3, 2021
@aspiers aspiers changed the title Fixes 'dot-' preprocessing fails for dot-directories (Savannah#56727) Fixes 'dot-' preprocessing fails for dot-directories (#33, Savannah#56727) May 3, 2021
@aspiers
Copy link
Owner

aspiers commented May 3, 2021

Thanks @AitorATuin, no further action necessary from your side - this is in my queue and will get to it as soon as I can. Scheduled for 2.3.3 due to the high levels of interest in this and #33.

@mortezadadgar
Copy link

How long this PR is going to stay unmerged here, just wondering

@d1egoaz
Copy link

d1egoaz commented Feb 8, 2022

bump 🙏

@rjekker
Copy link

rjekker commented May 30, 2022

I moved to another project (dotdrop) because the lack of active maintenance for stow.. This issue has now been open for 2 years!

@matteo-gambarutti
Copy link

@aspiers I was wondering if this project is still alive. I think it's a fantastic tool but it seems neglected for a while now.

monoflo added a commit to monoflo/stow that referenced this pull request Aug 13, 2022
@alator21
Copy link

alator21 commented Feb 5, 2024

@aspiers Hi. Is the project still alive? Can you please merge this?

@ghost-in-the-zsh
Copy link

Hi. I have some questions, not unlike others here and elsewhere:

  1. Will this ever get merged? If so, when?
  2. Will version 2.3.3 including this fix ever be released? If so, when?
  3. Otherwise, @aspiers : can you make an announcement explicitly stating this project is officially unmaintained?

I'm not sure ignoring an official GNU project you're the official maintainer for is the best thing to do, especially after several prior statements about how you're still committed to the project's progress and giving people hope that a new release with the fix will come "soon"(tm).

If you're no longer interested in this project, can you, please, at a minimum, give this project some closure by doing the following within the next 2-3 days or so:

  1. merge a fix (there're 2 different PRs with a fix to this issue);
  2. release 2.3.3 with a fix;
  3. explicitly state that 2.3.3 will be your final official release;
  4. explicitly announce you will no longer be maintaining this project.

This way, the community is officially and explicitly aware of the facts, won't waste time expecting something that will never materialize after said release, won't keep bugging you about it, and can either migrate to using a different tool or, perhaps even, fork the project and a have new official maintainer that's committed to the project's progress (whoever that person chooses to be).

Thanks in advance.

@jbwhit
Copy link

jbwhit commented Apr 3, 2024

@aspiers -- is there another GNU maintainer that can take this off your plate? There appears to be hands willing to help here.

@aspiers
Copy link
Owner

aspiers commented Apr 4, 2024

I've been working hard on the next release recently, including 4 solid days over the Easter weekend. Given my woeful absence from the project, I can totally understand this might sound like vaporware and yet more broken promises, so I've pushed the work in progress to the dev branch, so you can see all 117 new commits here: https://github.com/aspiers/stow/compare/dev

(Please note that GitHub orders that view from oldest to newest, so you'll have to scroll down and click the button to load more to see the latest. This is effectively a sneak preview of almost everything coming in the next release, which is right around the corner, although I still have a few more commits in progress.)

These 117 commits include a merge of this PR (with some alterations), and also properly eliminate the super annoying warning described in #65.

So to answer @ghost-in-the-zsh's very fair questions:

  1. Yes, this PR will get merged. It's merged into the above dev branch. However there were still some remaining issues with the fix, and over the last few weeks I came up with an improved approach which is almost ready to go.

  2. Yes, the next release will definitely include this fix, and I think there's an excellent chance I can get it done this weekend. I really thought (and fervently hoped) that the long weekend just gone would have been enough time to wrap this up and get a new release out. However whilst working on all of this, and coming back to Stow after a long time with a very rusty understanding of how all the nuances work, I realised that there was a lot of complexity in the code that was really hard to grok due to poor naming of variables / functions, missing comments, and confusing terminology, and it was really slowing me down. For example, here's a commit message I wrote about 30 mins ago:

testutil: rename parameter names to be less confusing

$target was the source of the link, and $source was the target
(destination) of the link. Obviously this was hopelessly confusing,
so rename to avoid this.

It doesn't take a rocket scientist to understand how this level of confusing naming schemes littered throughout the code could make it much harder to work with. Some of the good news is that a ton of that is already fixed in these 117 (and counting) new commits, I've blown away most of the cobwebs in my memory of how everything works, and now have a full understanding of how --dotfiles works. (I didn't write that code originally, I just merged it based on a partial understanding and on trust since it looked like a great contribution). This has not only made it easier for me to fix issues, it will make it easier for others.

However, even with all this new momentum, it's clearly time to get a new maintainer on board to ensure the project remains on a healthy footing. Even though I use Stow on a daily basis to manage my dotfiles, and therefore have a long-term vested interest in the project, it's obviously completely unacceptable to vanish as a maintainer for so long. Until 2020, I had a decent amount of free time for things like Stow. Then for various reasons (including co-founding a startup), I got exhaustingly busy. This is not an attempt at an excuse, or at dodging an apology. I am truly sorry for neglecting a project I love for so long, and I will write a full apology on the mailing lists along with the release announcement. I only mention this to provide an explanation, and to clarify that I absolutely have not lost interest in Stow.

But not having enough time to be the sole maintainer has harmed the project, and also caused me a great deal of guilt and anxiety. So I would like to find a strong co-maintainer who is able to review PRs, make releases when I'm unable to, perhaps help fix bugs, and is a good communicator and collaborator so that we don't end up stepping on each other's toes. Offers are welcome. BTW I have put quite a bit of effort over the years into documenting the release process, to raise the project's bus factor above 1.

However, this is not the right issue to be tracking that; we should start a new GitHub issue for expanding the maintainership team. And indeed, this is not the right issue for most of this message, but it's one which seems to have a lot of eyeballs, and I felt it was more important to break the silence and provide answers than to let my perfectionist tendencies cause further procrastination. I'll do more proper communications this weekend in the right places. My first priority is getting this release out of the door. Then I can start to clean up some of the other mess, make plans for the longer term.

@StephenWithPH
Copy link

I am truly sorry for neglecting a project I love for so long, and I will write a full apology on the mailing lists along with the release announcement.

But not having enough time to be the sole maintainer has harmed the project, and also caused me a great deal of guilt and anxiety.

Your users all know what we signed up for:

stow/COPYING

Lines 596 to 598 in 4ef5eca

PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

You contributed a useful thing to the world. Full stop.

To the extent that the project is now causing you grief, I apologize on behalf of your users. Thank you for the work you've done.

@nullman
Copy link

nullman commented Apr 4, 2024

@aspiers It's really cool to know that you are still working on this project. I've been using stow for years and didn't want to change to one of the other options unless absolutely necessary. I look forward to your update. Your work is very appreciated.

@aspiers
Copy link
Owner

aspiers commented Apr 4, 2024

Thank you very much for the kind words. It's not the project which was causing me grief, it was my poor prioritization and communication. I've definitely learned lessons here, and I'll do my best to avoid history repeating.

@aspiers
Copy link
Owner

aspiers commented Apr 4, 2024

we should start a new GitHub issue for expanding the maintainership team.

Filed as #104.

@aspiers aspiers self-assigned this Apr 4, 2024
@aspiers aspiers merged commit 2f762e3 into aspiers:master Apr 6, 2024
@aspiers
Copy link
Owner

aspiers commented Apr 7, 2024

v2.4.0 is released with this fix! See https://ftp.gnu.org/gnu/stow/

I'm just updating the website and preparing an announcement email.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug dotfiles Issues with --dotfiles option
Projects
None yet
Development

Successfully merging this pull request may close these issues.