-
Notifications
You must be signed in to change notification settings - Fork 227
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
fix: symlinks handling #3298
base: master
Are you sure you want to change the base?
fix: symlinks handling #3298
Conversation
I'm a bit unsure if we want to support this, how does it handle cycles? Might it not be better to just ask advanced users to copy files if they need to include them in multiple locations. They can wrap their |
It’s common use case for macOS/iOS plug-ins, third party libraries in ffi plugins etc In our case it forces us to remove directory with symlink to common scripts before publish pubignore also does not solve it since this check is done prior to application of ignore rules |
The only failing test should be one which ensures Previous behavior (pub bundled in dart 2.12 and behavior in current PR):
Current behavior:
If you insist this is expected behavior: I could try to move the check after resolving of ignored files and allow only ignored directory symlinks |
Hmm, it seems that in windows it fails to list dirrectory with loops in symlinks It differs from what is done on posix-like systems
|
Besides the cycle-handling this is looking quite good! |
jfyi: I had no time to reslove windows-related bugs lately, will continue in a few days |
Hi, today I finally found time to fix all problems on windows I'm going to take a look at the overall code style tomorrow, but otherwise it seems to be ready for review UPD: nope, as I've started to add comments with reasoning of this solution I found mistake, writing an additional test and fixing the problem now UPD2: now it should be definitely ready for review 😅 |
propagate visited symlinks through ordinary directories
@2ZeroSix, can you refresh my memory, how does this handle symlinks? With this symlink folders will be considered the same as if the folder had been copied. My concerns are:
|
@2ZeroSix is this mostly for ios/macos |
There is a few use cases:
In most use cases besides "code" directory symlinks are not meant to be published, but existing code throws an exception even for symlink that points to empty directory or ignored (works as expected only if you ignore whole parent directory of symlink) This pull request solves:
|
If that doesn't seem convincing enough, here is another way: here is spinoff of this pull request which allows anything (if it is ignored), but still forbids directory symlinks to be published After addition of proper loop detection it's pretty easy to adjust solution so it would throw only if symlinked directory or it's content isn't ignored |
This I'm sold we should allow.. I thought we did fix that, or did we never land the PR? |
Yeah, it was never landed. So lets consider what is the best behavior for pub:
It seems to me a bit illogical to allow file-symlinks but disallow directory-symlinks at the same time Anyway, I'm ok with any decision as on daily basis I mostly use symlinks for internal tooling that are not meant to be published |
This seems like a no-brainer. We're just correctly ignoring symlinks. I see how allowing non-cyclic directory symlinks could be nice, but the cost in terms of complexity (and ongoing maintenance) is non-trivial. So maybe this something we should reconsider, if there is a lot requests for it in the future. But right now it's not a highly requested feature, and in general most people are probably better off not using symlinks :D |
I would simply allow it for the sake of expectation. One should be able to get work everything which is working right now through Of course it's independent, but it's the most common workflow. I see that it could be misused by some devs, but honestly, so you can with code, your git history and everything else. The work every developer has to spend to circumvent this lack of feature takes more time and maintenance for all together and certainly brings more bugs, than having a collective and supervised mechanism for directory symlinks. But I'm also no messias, so this may brings the linking hell. But did it in git? |
Could we maybe re-open this one first: #3300 |
This PR has been open nearly 3 years. Frustrating that @jonasfj keeps knocking this down -- why? Maybe he doesn't know of a use case for it, but others clearly have them. Here's why it's illogical to shoot down this idea/PR: There are two use cases for symlinks in pub I can think of:
An example package I'm trying to publish: This package aides in generating FFI bindings for FFmpeg, and includes a default set of FFmpeg headers. The latest FFmpeg version is 7.1, so I created a 7.1 folder with those headers, and symlinked a So now I have to take yet more time and go rework my package (which @jonasfj also suggests I should write a wrapper around If the decision is so bad to allow symlinks, please explain. If it's bad practice, that wide-reaching decision should be backed up by fact, championed, and supported. There are a plethora of design decisions in Dart/Flutter that are, IMHO, far more complicated than they need to be, but I concede that allows flexibility. As a user of Dart/Flutter, I've had to learn these complexities and work with them. So why should a feature that users have been asking for since #3143 way back almost 4 years ago... be taken away with no other argument than "it's too complicated" and might be hard to maintain (speculative)? |
Thanks for pinging us! First of all we are sorry for neglecting this PR. Symlinks are problematic for several reasons
I would not say that symlinks don't have merit - and it is probably not warranted to completely disallow them. Just that they complicate things a lot, and that incurs a cost everywhere we handle files in pub. Please don't appeal to the age of an issue. We always try to prioritize issues we work on best we can, and cannot fix everything. Please don't call suggestions as "crazy" even if you don't find them helpful (read https://dart.dev/community/code-of-conduct) Even at google we are limited :) . This issue (mostly) has a work-around, so that is one reason we have not been as eager to resolve it as one could wish. That said, we hope to find time to pick up this PR again soon. It should really not have had to wait so long. |
fixes: #3143