#FeatureBlog - 18.3 - The New Package Manager

New day, new hot topic in the #BetaFollow-up series. This one is brought to you by @radutzp

The new Package Manager

I’m sure every one of you spent a lot of time waiting for the package list to load. And it always happened when you had a great idea on how to solve that problem. All you needed was one more custom activity that you knew exactly in which package can be found. And then, you had to wait for a looong time in order to just start typing the package name.
Not anymore! Coming in 18.3, the new Package Manager brings a fresh look and greatly improved performance. Moreover, some more or less hidden features are brought in the light. Features like setting up custom feeds and the search pagination. I know…

First of all, the package manager is now easier to find. The Manage Package button is moved to ribbon menu, so that everyone knows about it and can access it easily.

It can also be found where you need it most: near your dependencies.

Let’s open it and get a glimpse of the new look and feel of it:

As you can see, it got a revamped look and a more intuitive layout. Now, we should dive deeper into it. On the left side, there is the improved navigation panel.

  1. Settings page: from here you can add/remove source feeds

  2. On this page you can check out the packages used in the current project

  3. All the available package feeds: default and the ones you have set up

In the middle section, there are a few changes as well….

The biggest changes were done in the package list. Most important, the search is almost instantaneous. No more waiting for every slow feed in order to see your results.

Also, the page number is not “hidden” anymore…welcome infinite scroll!

On the packages side we added the following:

  1. Installed package indicator

  2. An inline button for removing a dependency

  3. An update package button to the latest version.

  4. Pending install indicator

  5. The installed and the latest available versions

From now on, you can add or remove packages in your list like filling up a shopping cart and the dependencies will be installed only at checkout. This speeds up the process considerably.

On the package details side you will notice that we added a Runtime rule dropdown which describes how the dependencies will be resolved at…well…runtime. Anyway, this will be discussed in further detail on a future topic on dependencies.

Last but not least: the Settings page. Here you can see and manage the package feeds. It has two sources lists: the default feeds (1) and the custom ones (3). You can even add your own from the + sign (2). It can be any local folder or nuget feed you want.

When connected to the Orchestrator, the Library feed magically appears in the list. This helps you a lot when using and sharing reusable components. In the Orchestrator Feed, you will have all the libraries which were published by you and your team to Orchestrator. Unfortunately though, for the 2018.3.0 version, this is available only for on premise Orchestrator deployments.

That was all about the new Package Manager. I hope you like it as much as we do! Let us know your thoughts and don’t forget to fill up the list with your Reusable Components!

9 Likes

Thanks, this is very appreciable, especially if you have several feeds such as beta/community ones when you were going to all available.
That was sometime a bit awkward during demo sessions:).

On the package details side you will notice that we added a Runtime rule dropdown which describes how the dependencies will be resolved at…well…runtime. Anyway, this will be discussed in further detail on a future topic on dependencies.

That will definitely resolve some issues for Robots running more than one process developed at different dates (and package versions) or in some case but also HDR issues in regards of package version.

Should we understand that robots will be syncing more than one package version if the dependency is needed?

Previous version limiation was

The latest available version of an activity is always used in all the processes deployed to a machine with multiple Robots (High-Density Robots), even if you had different versions of activities in your packages. For example, if you have 6 processes deployed to multiple Robots from the same machine as follows: 5 processes that use version 1.1 of an activity, and one process that uses version 1.2 of the same activity; all 6 processes are going to use version 1.2 of the activity

I imagine you intend to provide more info later on that as you mentioned.

All good on this update!

Cheers

1 Like

@ovi
What I observed from above post is for every project we need to install required packages and they will be included in project as dependencies while publishing. so there won’t be any dependency on packages if we run the process on attended robot with out orchestrator.
please correct me if I am wrong…

Would it be possible to have a default set of packages to be added at project creation? Maybe a custom template to apply for a project that will have all desired packages automatically added as project’s dependencies?

1 Like

Some default packages were already added while creation such as core activities, excel, mail etc., but when we need pdf, ftp, python credentials we need to add manually while creating the project.

It will be great if there is a way to add more packages into the default dependency. For some packages we’ve been using them a lot. Will be great if we do not need to install again each time we start with a new project.

1 Like

Hi @pathrudu

True.

No matter if the Robot is running locally or via Orchestrator, it will download the package version you have set at design time specifically for the project you are running.

1 Like

@MirceaGrigore please explore this idea of making some activity packs defaults (i think it could be something like Add to Favorites option for individual activities)

Hey Florent,

Aaand here it is: https://forum.uipath.com/t/betafollow-up-dependencies-per-project-dependency-rules/63536

1 Like

It would be nice to have the option to update all the packages having an update available at once, as in the previous versions.

Hi Ciprian,

The Update All button was removed so that you wouldn’t update a package and not knowing about it. Dependencies per project were introduced and now it’s really important from design time which package version you are using for a specific project.

But you can share here your reasons and product team will take into consideration bringing it back if it’s really useful for developers.

Thanks,
Viorela

Ok. I see the reason for not updating all at once via one single click, but at least keep the group “Updated” to quickly see the ones that have an update available.

1 Like

@MirceaGrigore what do you think?

Just to see if i understand exactly the request: You want to see a list of those dependencies that have updates available and next the ones that are up-to-date? Or some sort of grouping / order. Is this correct? We might have something like that in the future.

1 Like

I want to see all the installed packages that have updates, in a group under “All Packages”

Save as Template in 18.4 (currently in beta) allows creating custom project templates which include any package dependency with any rule and any default workflows. It’s as if being able to create your own REFramework. Be sure to check it out and give us some feedback. Cheers!