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

dub lint should only lint source files (excluding ignored ones) #2700

Open
WebFreak001 opened this issue Sep 24, 2023 · 7 comments
Open

dub lint should only lint source files (excluding ignored ones) #2700

WebFreak001 opened this issue Sep 24, 2023 · 7 comments

Comments

@WebFreak001
Copy link
Member

Currently dub lint simply calls dscanner in the package directory, this should be changed so that it calls D-Scanner for each source file, probably using an arguments/.rst file

Otherwise it will instruct D-Scanner to scan also temporary files such as the .d files that are emitted by some build tools as temporary files.

@chances
Copy link

chances commented Sep 24, 2023

For example, dub lint ought not scan sources specified in excludedSourceFiles.

bhelx pushed a commit to extism/extism that referenced this issue Oct 23, 2023
See [dlang.org](https://dlang.org).

SDK Coverage: ~91.30%	(21/23)

## Issues 

- [x] These symbols are undefined in the latest release
([v0.5.2](https://github.com/extism/extism/releases/tag/v0.5.2)):
    > Undefined symbols for architecture x86_64:
    > "_extism_plugin_id"
    > "_extism_plugin_new_error_free"
    
    Using `libextism` compiled from source does _not_ have this issue.
- [ ] `dub lint` reads many intermediate targets files:
dlang/dub#2700

## Todo List

- [x] Flesh out initial binding
- [ ] Cover host API:
  - [x] `ExtismFunctionType`
    See `FunctionType` alias.
  - [x] `extism_plugin_id`
  - [x] `extism_plugin_new_error_free`
  - [ ] `extism_plugin_error`
- [ ] Add unit tests
- [x] Add usage example

---------

Co-authored-by: zach <[email protected]>
bhelx pushed a commit to extism/d-sdk that referenced this issue Oct 23, 2023
See [dlang.org](https://dlang.org).

SDK Coverage: ~91.30%	(21/23)

## Issues 

- [x] These symbols are undefined in the latest release
([v0.5.2](https://github.com/extism/extism/releases/tag/v0.5.2)):
    > Undefined symbols for architecture x86_64:
    > "_extism_plugin_id"
    > "_extism_plugin_new_error_free"
    
    Using `libextism` compiled from source does _not_ have this issue.
- [ ] `dub lint` reads many intermediate targets files:
dlang/dub#2700

## Todo List

- [x] Flesh out initial binding
- [ ] Cover host API:
  - [x] `ExtismFunctionType`
    See `FunctionType` alias.
  - [x] `extism_plugin_id`
  - [x] `extism_plugin_new_error_free`
  - [ ] `extism_plugin_error`
- [ ] Add unit tests
- [x] Add usage example

---------

Co-authored-by: zach <[email protected]>
@Imperatorn
Copy link

Any update on this?

@WebFreak001
Copy link
Member Author

I don't think any work has been started on this yet

@maxhaton
Copy link
Member

maxhaton commented Jan 2, 2024

Does dub even need to be linting?

@maxhaton
Copy link
Member

maxhaton commented Jan 2, 2024

dub is already too complicated, surely this could go entirely, surely?

I can't think of a time when I've wanted my package manager to lint

@PetarKirov
Copy link
Member

PetarKirov commented Jan 13, 2024

@maxhaton most language ecosystems I've interacted with in recent years, what you would typically call package manager has evolved into a task runner and/or even a simple build system (like dub). While one may argue that having this functionality built into Dub is scope creep, to answer your point directly:

I can't think of a time when I've wanted my package manager to lint

A few examples:

I'd be in favor of removing dub lint if we could over a drop in replacement in a form similar to package.json scripts: https://yarnpkg.com/configuration/manifest#scripts

@maxhaton
Copy link
Member

@maxhaton most language ecosystems I've interacted with in recent years, what you would typically call package manager has evolved into a task runner and/or even a simple build system (like dub). While one may argue that having this functionality built into Dub is scope creep, to answer your point directly:

I can't think of a time when I've wanted my package manager to lint

A few examples:

I'd be in favor of removing dub lint if we could over a drop in replacement in a form similar to package.json scripts: https://yarnpkg.com/configuration/manifest#scripts

Fair enough although that doesn't quite match my point about desire — i.e. I personally have never reached for anything like this, and I'm usually pretty wary of off-the-peg linting in general because it can take a bit of fiddling to get things where you want, and by the time you've done that you could've done it yourself from scratch (e.g. you might only want to lint code that directly relates to a git commit etc etc)

Anyway, scripts would be good in that dub as a codebase suffers from using way too much abstraction to implement relatively concrete tasks, so maybe it can be the generic thing it always wanted to be.

As it stands I just can't see the complexity paying for itself.

In the short term though I think cutting down would be good, and also probably not trying to enforce too many defaults e.g. dub profile builds seem like a nice idea except that they only really expose the built in profiling DMD can expose (IIRC) which is deeply flawed, so people get tripped up all the time.

Similarly unittests. Having a universal entry to tests is a good scaling but win it should explicitly just be some kind of task runner as you say.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants