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

add some missing PackageName overloads #2867

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

WebFreak001
Copy link
Member

No description provided.

Copy link

github-actions bot commented Feb 17, 2024

✅ PR OK, no changes in deprecations or warnings

Total deprecations: 0

Total warnings: 0

Build statistics:

 statistics (-before, +after)
 executable size=5372576 bin/dub
 rough build time=62s
Full build output
DUB version 1.35.1, built on Jan  6 2024
LDC - the LLVM D compiler (1.36.0):
  based on DMD v2.106.1 and LLVM 17.0.6
  built with LDC - the LLVM D compiler (1.36.0)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver3
  http://dlang.org - http://wiki.dlang.org/LDC


  Registered Targets:
    aarch64     - AArch64 (little endian)
    aarch64_32  - AArch64 (little endian ILP32)
    aarch64_be  - AArch64 (big endian)
    amdgcn      - AMD GCN GPUs
    arm         - ARM
    arm64       - ARM64 (little endian)
    arm64_32    - ARM64 (little endian ILP32)
    armeb       - ARM (big endian)
    avr         - Atmel AVR Microcontroller
    bpf         - BPF (host endian)
    bpfeb       - BPF (big endian)
    bpfel       - BPF (little endian)
    hexagon     - Hexagon
    lanai       - Lanai
    loongarch32 - 32-bit LoongArch
    loongarch64 - 64-bit LoongArch
    mips        - MIPS (32-bit big endian)
    mips64      - MIPS (64-bit big endian)
    mips64el    - MIPS (64-bit little endian)
    mipsel      - MIPS (32-bit little endian)
    msp430      - MSP430 [experimental]
    nvptx       - NVIDIA PTX 32-bit
    nvptx64     - NVIDIA PTX 64-bit
    ppc32       - PowerPC 32
    ppc32le     - PowerPC 32 LE
    ppc64       - PowerPC 64
    ppc64le     - PowerPC 64 LE
    r600        - AMD GPUs HD2XXX-HD6XXX
    riscv32     - 32-bit RISC-V
    riscv64     - 64-bit RISC-V
    sparc       - Sparc
    sparcel     - Sparc LE
    sparcv9     - Sparc V9
    spirv32     - SPIR-V 32-bit
    spirv64     - SPIR-V 64-bit
    systemz     - SystemZ
    thumb       - Thumb
    thumbeb     - Thumb (big endian)
    ve          - VE
    wasm32      - WebAssembly 32-bit
    wasm64      - WebAssembly 64-bit
    x86         - 32-bit X86: Pentium-Pro and above
    x86-64      - 64-bit X86: EM64T and AMD64
    xcore       - XCore
   Upgrading project in /home/runner/work/dub/dub/
    Starting Performing "release" build using /opt/hostedtoolcache/dc/ldc2-1.36.0/x64/ldc2-1.36.0-linux-x86_64/bin/ldc2 for x86_64.
    Building dub 1.36.0+commit.107.g3828ae85: building configuration [application]
     Linking dub
STAT:statistics (-before, +after)
STAT:executable size=5372576 bin/dub
STAT:rough build time=62s

Comment on lines +1957 to +1961
// TODO: we want to deprecate this overload, however we can't really do
// that until the selectedPackages exposes PackageName, otherwise this
// doesn't work without warning, but obviously should:
// foreach (key; project.selections.selectedPackages)
// ... = project.selections.getSelectedVersion(key);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following will work:

project.selections.getSelectedVersion(PackageName(key));

Not ideal but PackageName.this is fairly light.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that really doesn't look like its intended API for how to iterate over selected packages though, selectedPackages should obviously just return PackageName[] instead - getSelectedVersion should only take as input what selectedPackages returns (string) - we don't want to encourage the library users to put PackageName(...) everywhere, it should just be constructed where explicitly needed, e.g. when converting from user input (string) to it. When it comes from the library it should be PackageName everywhere where applicable.

Also, while I toyed around with this tried to use PackageName everywhere, it quickly looked like an issue that PackageName.main also returns PackageName - we should probably have an extra type like RootPackageName that is not allowed to have any sub-package in it. (it can implicitly convert into PackageName though) Otherwise it can quickly become ambiguous and will quickly suffer from the same problems as using string everywhere. We should definitely add such a type before PackageName is rolled out as library part.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that really doesn't look like its intended API for how to iterate over selected packages though, selectedPackages should obviously just return PackageName[] instead - getSelectedVersion should only take as input what selectedPackages returns (string) - we don't want to encourage the library users to put PackageName(...) everywhere, it should just be constructed where explicitly needed, e.g. when converting from user input (string) to it. When it comes from the library it should be PackageName everywhere where applicable.

Yes. Unfortunately we can't do overloads based on return type. Same reason why Package.name is still string. This will be a v2 change. So the current state is IMO the best compromise. We could also just introduce an overload, e.g. byKey, that returns PackageName.

Also, while I toyed around with this tried to use PackageName everywhere, it quickly looked like an issue that PackageName.main also returns PackageName - we should probably have an extra type like RootPackageName that is not allowed to have any sub-package in it. (it can implicitly convert into PackageName though) Otherwise it can quickly become ambiguous and will quickly suffer from the same problems as using string everywhere. We should definitely add such a type before PackageName is rolled out as library part.

I hit a similar problem. In practice, dependency resolution barely cares about non-base/root package names because the version for subpackages is always the same. Likewise for dub fetch. But at least this is now somewhat visible / documented in the code. Note that the original version of PackageName returned string for main. It didn't work well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there have already been backwards incompatible changes in this regard, so I'd suggest we just edit some things such as the selections and other places where it's obvious immediately and break this usage all at once instead of breaking parts of it every release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do we have backward incompatible changes ? I never intended to make breaking changes, that's why there are so many deprecated overloads in Dub ATM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok sorry turned out it's just a single thing that I had to deal with, so it's not so bad, however it did need changes:

  • PackageDependency.name from Package.getAllDependencies() changed to PackageName without deprecation period

I really like the PackageName change and would like to use it in more places. My suggestion would be for more rarely used APIs to already change them to PackageName early.

Should package names inside the recipe struct be of type string or PackageName? PackageName implies semantics that it would have been checked already so I don't think it'd be the right thing that early on. Also we need a parse method that actually verifies the contents and some kind of fromTrustedString method that asserts on error, similar to the vibe.d APIs for stuff like paths.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PackageDependency.name from Package.getAllDependencies() changed to PackageName without deprecation period

Let me have a look at it. It was a bit annoying to deal with PackageDependency when doing the migration, but I found a way to make it work. However, it might have been relying on the alias this which I then removed...

Should package names inside the recipe struct be of type string or PackageName? PackageName implies semantics that it would have been checked already so I don't think it'd be the right thing that early on.

In general we should check user input as early as possible. Having it checked when parsing makes sense to me because we can then point the user to the right place. Configy has various hooks (fromString, constructor overloads) that it can call, and if they throw, it will display the error message with all the required information.
For example:

File Edit Options Buffers Tools D Help
/++ dub.json:
 { "name": "test", "dependencies": { "configy": "*" } }
+/
module c;

import std.format;
import std.stdio;
import configy.Read;

struct PackageName {
    this (string value)
    {
        if (value != "42")
            throw new Exception("Value %s is not right".format(value)\
);
    }

    private string val;
}

struct Nested { PackageName name; }
struct Recipe { Nested nested; }

void main ()
{
    try
        parseConfigString!Recipe(`{ "nested": {
 "name": "notQuiteRight"
}}`, "dub.json");
    catch (ConfigException exc)
        writefln("%S", exc);
}

This displays (with colors):

% dub c.d
dub.json(1:9): nested.name: Value notQuiteRight is not right

So it would be fairly trivial to do this change, however it's a breaking change. We are getting closer to a point where Dub 2.0 is inevitable and I'd prefer to pack the breaking changes for that moment.

@Geod24
Copy link
Member

Geod24 commented Feb 24, 2024

@WebFreak001 : Can we move forward here ?

@WebFreak001
Copy link
Member Author

yeah does anything need to be changed?

@Geod24
Copy link
Member

Geod24 commented Feb 24, 2024

I would say limit it to adding the overload, and keep the deprecation / comment out ?

@Geod24
Copy link
Member

Geod24 commented Jun 18, 2024

Ping @WebFreak001

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

Successfully merging this pull request may close these issues.

2 participants