@philfreo The repository is designed to be published to GitHub pages. It is also designed to be used with Pow in my local development environment, hence the need for the public dir.

I'm not familiar with Django's collectstatic, but it sounds like it has a bug (or an undesirable feature) that's worth fixing there. It looks like collectstatic also has support for ignoring directories matching a glob pattern.

You're free to further justify a change to the timeago repository, but given my development workflow, it's currently unlikely that I'll accept this patch.

"a bug (or an undesirable feature)"

public is a symlink to itself: Including a reference to a directory within itself is mind-boggling. What sort of environment of you use, @rmm5t ?

Do you traverse this way...:

jquery-timeago$ cd public
jquery-timeago/public$ cd public
jquery-timeago/public/public$ cd public

...or more like this? jquery-timeago$ cd public/public/public/public/public/public

:-D

If this is just your personal development repository (and seeing as you're defending infinite recursion) then I guess ths stays closed!

@appastair I do not understand nor do I appreciate the snarky nature of your comment. Were you not happy with my original explanation?

public is a symlink to itself

Not true. public is a symlink to its parent directory.

The parent directory hosts the documentation page and the test suite that I access for final testing before a release. As I've already explained, I use GitHub pages for publishing this project and Pow to manage the dozens of projects that I work on day-to-day, and being able to access each by name without worrying about virtual host config entries and without starting servers on random ports is a productivity boost. Pow relies on a public directory for static content, and the symlink prevents me from ever having to think about or work in the public directory. E.g. I can access static content at http://timeago.dev/ at anytime simply because my timeago directory has a public directory in it.

and seeing as you're defending infinite recursion

Hey look, a scarecrow! I never defended infinite recursion. The public symlink is perfectly accessible as it is, because it is not infinite recursion (unless you're defending the case of perpetually changing to the same directory again and again for the hell of it).

Next time, please consider explaining a problem that you're actually having. Is it that your toolchain can't handle this public symlink? I would suggest adding some ignore rule to your tools, or perhaps you should take the underlying issue up with the maintainers of that tool.

Whining about how I setup my environment doesn't make it conducive for me to help you. Better yet, come up with an alternative solution that meets the underlying requirements and propose that.

😄

Sorry. I did mean the parent directory, not itself but the infinite
recursion was what I was referring to. I noticed it first because of
NetBeans IDE but I don't see why it shouldn't be much more widespread.

I understand your workflow but it seems that it's causing issues (though
very minor) for some people and as it's used by lots of people, if it was
my workflow that the link was for, I'd add echo "public" >> .gitignore but it isn't so thanks for the neat plugin and ongoing work.
Sorry for the snark. :-(
On 31 Jan 2013 02:55, "Ryan McGeary" [email protected] wrote:

@appastair https://github.com/appastair I do not understand nor do I
appreciate the snarky nature of your comment. Were you not happy with my
original explanation?

public is a symlink to itself

Not true. public is a symlink to its parent directory.

The parent directory hosts the documentation page and the test suite that
I access for final testing before a release. As I've already explained, I
use GitHub pages http://pages.github.com/ for publishing this project
and Pow http://pow.cx/ to manage the dozens of projects that I work on
day-to-day, and being able to access each by name without worrying about
virtual host config entries and without starting servers on random ports is
a productivity boost. Pow relies on a public directory for static content,
and the symlink prevents me from ever having to think about or work in the
public directory. E.g. I can access static content at http://timeago.dev/at anytime simply because my timeago directory has a public directory in it.

and seeing as you're defending infinite recursion

Hey look, a scarecrow http://en.wikipedia.org/wiki/Straw_man! I never
defended infinite recursion. The public symlink is perfectly accessible as
it is, because it is not infinite recursion (unless you're defending the
case of perpetually changing to the same directory again and again for the
hell of it).

Next time, please consider explaining a problem that you're actually
having. Is it that your toolchain can't handle this public symlink? I would
suggest adding some ignore rule to your tools, or perhaps you should take
the underlying issue up with the maintainers of that tool.

Whining about how I setup my environment doesn't make it conducive for me
to help you. Better yet, come up with an alternative solution that meets
the underlying requirements and propose that.

[image: 😄]

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/57#issuecomment-12896116.

I noticed it first because of NetBeans IDE but I don't see why it shouldn't be much more widespread.

Why would it be more widespread? What are IDEs like NetBeans doing that causes them to go into infinite loops? Why do they need try to traverse all directories?

The fact that the file system itself and the GUI tools around it that come bundled with the operating system can handle a recursive symlink without blowing up is perfect evidence why the NetBeans behavior is broken.

Lastly, what were you trying to do with the repository that landed you in NetBeans hell? Were you planning to fork it and submit a pull-request? Were you pulling it into your work repository in the form a of a git submodule (or similar) for inclusion in your project? I'd like to understand the workflow that led to this discussion.

I noticed it by adding it as a submodule and NetBeans issues an error whenever I search for something.

public could not be read: Can't read /home/my-repo/jquery-timeago/public/{40}

Further testing in the shell doesn't give the same recursion from anything I tried so apart from manually cding ad nauseam, it seems to be beyond the scope of this repo. but in any case, when I got some time I'll see if I can come up wth something that meets your requirements while keeping NetBeans at bay and do a pull request.

@appastair Thanks for the additional details. Honestly, you should consider submitting a bug report to NetBeans.

NetBeans Bug 218795 - FileObject.getChildren(true) should handle recursive symlinks gracefully

Update: I reconsidered this issue mainly because I'm tired of hearing about projects that are forced to use tools with this common bug of not being able to handle symlinks properly. I removed the public symlink.

I feel like one of the bad guys now... 😦 I completely understand where you were coming from and I'm not so familiar with any of the more popular tools that have this issue but in my experiences, at least it's rarely an issue.

I guess...that's how it goes with everything IE : Instead of doing the correct thing, one has to begrudgingly go the extra distance because other people won't fix their broken/non-compliant stuff! 😉