dragonbox / uplift Goto Github PK

As a new feature it would be nice to support the integration of a nuget repository as an uplift repository

Some packages, such as Humanizr, that are standard .net foundation compliant, must be integrated in our project as nuget packages

The behaviour described by this unit test

[Test]
            public void ResrictToMinimalRequirement()
            {
                MinimalVersionRequirement minimalRequirement;
                // When greater (1.1+)
                minimalRequirement = new MinimalVersionRequirement("1.1");
                Assert.Throws<IncompatibleRequirementException>(
                    delegate
                    {
                        requirement.RestrictTo(minimalRequirement);
                    }
                );

                // When more specific 1.0.4+
                minimalRequirement = new MinimalVersionRequirement("1.0.4");
                Assert.AreSame(requirement.RestrictTo(minimalRequirement), minimalRequirement);

                // When lesser (0.9+)
                minimalRequirement = new MinimalVersionRequirement("0.9");
                Assert.AreSame(requirement.RestrictTo(minimalRequirement), requirement);
}

is not completely correct: the second scenario is non sense and enables scenarii such as:

• A depends on B 5.2
• C depends on B 5.2.1+
• Uplift merges those conflicts as B 5.2.1+, and later on chooses 5.5.2 which is incorrect behavior for first dependency.

Some .unitypackages are considered and not extracted correctly. This is due to a weird difference in the structure of the archive.

The need to maintain both the packageexport.asset and the templateUpset.xml in a project is cumbersome and should be streamlined, by putting the depencies and the configuration into the asset directly.

To do this, we need to:

• Extract the custom fields we use in the UpfileEditor.cs to keep things DRY
• Introduce the dependencies and the configuration in the scriptable object

What needs to be considered:

• Backwards compatiblity: any system relying on the packageexport.asset would fail if it relies on an template Upset. Should we then accept breaking changes (after all we're still in beta), or provide some sort of migration mechanism, perhaps relying on an Asset Processor?

It is possible to move the whole CLI arguments into a responsefile for mono/mcs

See

and here for the implementation
https://github.com/mono/mono/blob/mono-4.0.0.121/mcs/mcs/settings.cs#L620

The .gitignore are generated with CRLF and it causes conflicts in some of our projects where we force line endings to LF.

My hope is uplift is under MIT, because I favor it for its taking back control from unity over the unity package manager. However the docs say, "all rights reserved" I wanted to confirm it is under MIT going forward.

https://dragonbox.github.io/uplift_site/index.html#license-copyright-authors

I have two dependencies on the same package, 0.9 and 0.9.* which are compatible, as all versions matching 0.9.* match 0.9. Yet Uplift throws an error saying they're not compatible.

When releasing with the development tools, the version is not kept up to date in the README.

The update window, still experimental has several issues regarding the integrity and the consistency with the Upfile and the Upfile.lock

• it is possible to update a package in this window even though the updated version would conflict with the requirements of the project. If we want to support this, we should at least warn that this may seriously break a project.

• udpated dependencies in this fashion are not updated in the lockfile.

I installed a newer version through a local repo, which I removed from my upfile later on.
Then the update window showed this:

outdated package but I have a newer one.

one for 2017.4, one for 2018.4

We could probably use the Github API for finding out about releases.

See https://api.github.com/repos/DragonBox/uplift/releases

We could use a JSON parser. If we limit the support of self-updates to Unity 5.3 and above, we could use Unity's own JSON parser. I'll give it a try.

I've encountered an issue while using "Install dependencies (as specified in lockfile)". Several times, my lockfile was modified after this operation.
It does not happen at each time, but I figured out a case in which it happens.

Initial state of the lockfile :

[...]
# SOLVED DEPENDENCIES
A 1.0
    B 1.0+
B1.1

Then I updated B to 1.2 version

[...]
# SOLVED DEPENDENCIES
A 1.0
    B 1.0+
B1.2

And after running "Install dependencies (as specified in lockfile)", and the lockfile is modified as followed :

[...]
# SOLVED DEPENDENCIES
A 1.0
    B 0.9+
B1.2

And 0.9+ was a transitive dependency in a previous version of my package A.

I noticed that sometimes if I bump a dependency under my Upfile, the # SOLVED DEPENDENCIES section get updated, but the # UPFILE DEPENDENCIES doesn't.

In the perspective of Uplift leaving beta, I believe we should clean its UI. Finalizing the experimental windows, and overall spending some time designing the UI wouldn't go amiss.

What should be targeted in my opinion:

• First and foremost the UpfileEditor.cs, by extracting our custom fields to a common class (something like UpliftGUILayout), as suggested in #47 , and redesigning this window
• The other windows
• The inspector for the PackageExport

What could be done:

• Maybe create a "hub" with different tabs to have a single GUI entry point?

When running Uplift with the .unitypackage from the releases, logs are not aggregated and the message On Unity < 5.3, Uplift doesn't aggregate logs shows up. But running with the source code, the log are correctly aggregated and the message doesn't appear.

Despite the presence of a refresh option in the code it doesn't actually work, resulting in some less than explainable issue.

It is because we create an instance of the UpliftManager, from which we reset instances.