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

provide feature #16

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@tarsius
Copy link
Contributor

tarsius commented Jan 6, 2015

No description provided.

@lunaryorn

This comment has been minimized.

Copy link
Contributor

lunaryorn commented Jan 6, 2015

@tarsius Why? This is a non-interactive tool, not a library intended to be loaded into a running Emacs. As a matter of fact, you can't even do so, because loading this file as global side-effects that are actually harmful in an interactive Emacs session.

IOW, this isn't a feature, so we shouldn't provide anything at all.

@tarsius

This comment has been minimized.

Copy link
Contributor

tarsius commented Jan 6, 2015

Almost all packages contain a "feature". That's why, when I add a package to the Emacsmirror, I check whether the correct feature is provided. If it is not then that is usually because the author is very new to the game, and after closer inspection I decide that I don't want to mirror the package anyway.

And then there is ert-runner which looks like a useful tool. But if you don't want to provide a feature that's okay too, I just cannot mirror it then, because I do not want to add a special case for a single package.

@lunaryorn

This comment has been minimized.

Copy link
Contributor

lunaryorn commented Jan 6, 2015

@tarsius Respectfully, we are not “new to the game”… and we (@rejeep actually) omitted provide for a reason: provide implies that it's safe to require the file, and ert-runner.el is not. It'll break if required in an interactive Emacs session. We'd give a false promise, if we added provide.

And why should we anyway? This is clearly a non-interactive tool. You'd never require it anyway.

I don't see how that is related to mirroring, though. Git doesn't care whether there's provide in here or not.

That said, it's your choice to mirror what and how you want, of course, but I would not like to add a misleading—to say the least, I'd rather say “wrong”—provide just to support arbitrary requirements of a particular mirror.

@tarsius

This comment has been minimized.

Copy link
Contributor

tarsius commented Jan 6, 2015

Respectfully, we are not “new to the game”

Never said you were. Newcomers often don't provide a feature by mistake, that doesn't mean that not providing always is a a mistake. If you don't provide a feature, and if it is by mistake, of course does not make you a beginner in my eyes.

… and we (@rejeep actually) omitted provide for a reason: provide implies that it's safe to require the file, and ert-runner.el is not. It'll break if required in an interactive Emacs session. We'd give a false promise, if we added provide.

And why should we anyway? This is clearly a non-interactive tool. You'd never require it anyway.

That's a good argument, and if I had spend a little more time on it I would have noticed. But I have dedicated this day to mirroring an additional 1100 packages, so please forgive me for cutting a corner here.

I don't see how that is related to mirroring, though. Git doesn't care whether there's provide in here or not.

I am actually building a dependency tree, mainly to detect packages which bundle third-party libraries. Being able to determine which features are provided by a package is essential.

That said, it's your choice to mirror what and how you want, of course, but I would not like to add a misleading—to say the least, I'd rather say “wrong”—provide just to support arbitrary requirements of a particular mirror.

That's fine. I don't fully agree with it being "wrong" to provide a feature anyway, but I understand your reasoning. I hope you understand that I am not not mirroring your package because of such disagreements, but because it's just more efficient to first mirror the other packages which I can import without having to deal with special cases (however justified they might be).

@tarsius tarsius closed this Jan 6, 2015

@rejeep

This comment has been minimized.

Copy link
Owner

rejeep commented Jan 7, 2015

@tarsius Would like to see that dep-tree. But like @lunaryorn, there's really no point in providing this package.

@lunaryorn

This comment has been minimized.

Copy link
Contributor

lunaryorn commented Jan 7, 2015

@tarsius As I said, you are free to mirror whatever and however you want. It doesn't bother me if you don't mirror this repository.

@tarsius tarsius referenced this pull request Nov 30, 2015

Closed

Melpa packages missing from the Emacsmirror #65

11 of 33 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment