Package Name Standardisation

[jgcode]

Daklu made an interesting point on this thread about if there is any internal standardisation of package names at NI.

Do we need naming standardisation?

I think yes, and IMO now is the time to do it with the LabVIEW Tools Network kicking off and VIPM/packages being NI's distribution method of choice.

Can we, the open source community at LAVA, lead the way for standardisation (I think yes here too)?

As for me I copied VIPM's original naming convention for all packages (.vip and .ogp), as well as what was already out there.

Along the way I added some of my own as the need arose.

I try to be as consistent as possible (sometimes I am not!)

The following are some examples of types of packages and keywords I use, as well as the name format for the package:

lib = Library: [Type] Internal Reuse Library

E.g. jgcode_lib_developer-1.4.0-1

rsc = Resource: [Type] Not reusable code. This can include palettes, templates, hooks, LabVIEW menu (wizard, project etc...)

E.g. jgcode_rsc_jgcode_toolkits_palette-1.1-1

class = LVOOP Class: [Keyword] Contains Library/Classes designed to be extended etc... (as opposed to an non-extend-able API)

icon_lib_class_variant_map-1.0-1

qdp = Quick Drop Plugin: [Keyword]

E.g. jgcode_rsc_qdp_lvoop_assistant-0.11.1-1

rpk = Repack: [Type] Repacked some else's code, need to use the code but it wasn't available as a package. None of the original code is changed.

E.g. jgcode_rpk_ni_system_style_daqmx_controls-1.0-1

fix = LabVIEW Fix: [Type] Exclusively released by NI and overwrites LabVIEW shipping files (something I don't normally like to do)

E.g. jgcode_fix_ni_apply_icon_to_vis_buttons-1.0-1

tool = Tool: [Type]: I started using this keyword for LabVIEW tools (e.g. Project Folder) but have considered dropping it in favour of rsc

E.g. icon_tool_open_icon_folders-1.1-1

Another format I have considered is for releasing code that is not quite up to production but I want to manage it's release using a package (that's a great thing about packages - they're version controlled). Haven't come up with a standard name for that yet tho.

I am interested to hear how others divide up their distributions.

What is everyones opinion on this?

[crelf]

I think it's even more important to have *categories*, not name standardization. I can image the default view in VIPM getting pretty unruly once a few more packages are released.

For example, if I'm looking for some DAQmx stuff and I sort by package name " jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" won't help me.

[Christian_L]

I think it's even more important to have *categories*, not name standardization. I can image the default view in VIPM getting pretty unruly once a few more packages are released.

For example, if I'm looking for some DAQmx stuff and I sort by package name " jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" won't help me.

Agreed. Now that VIPM shows package names instead of the file name (assuming the package has a name), standardizing the file name, while desirable, is not as important anymore.

Having groupings or categories is more desirable. Even searchable tags would be good to have.

I did define a similar standardization for VI package created by Systems Engineering. I defined the following categories:

lib - all non extensible code including classes

util - corresponding to your rsc and tool

tmpl - all templates, design patterns, extensible classes, etc.

The challenge we found is that several packages would include more than one type of content, e.g. they would have an API (lib) and also add an entry to the Tools menu/project folder (rsc).

[jgcode]

I can image the default view in VIPM getting pretty unruly once a few more packages are released.

I definitely agree with the above - more and more packages is only going to make this worse.

I think it's even more important to have *categories*, not name standardization... ...For example, if I'm looking for some DAQmx stuff and I sort by package name " jgcode_rpk_ni_system_style_daqmx_controls-1.0-1" won't help me.

That's why I prefer to use the search bar

So do you lead the package name with the Category then?

I do like this idea of a new feature called Category that appears in the Listbox so you can sort by it.

This should follow NI's terminology (string, numeric, array etc..) and should definitely be standardised IMO.

[Michael Aivaliotis]

Even though package filenames\unique identifiers are important. They are not that critical with the latest release of VIPM 2010. We don't display these anywhere in the user interface of the VIPM install process or even in the package list. We are now using Product Names. So if you are building a package with VIPM 2010 (jgcode, why aren't you?), you can now specify a user friendly Product Name which is independent of the package filename\unique identifier.

Yes, package filename\unique identifier are important, since this is what VIPM uses to determine package upgrades.

As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool).

As far as categories and tags. Yes! we agree that this is a great feature to have in VIPM. But we don't have it yet.

[jgcode]

The challenge we found is that several packages would include more than one type of content, e.g. they would have an API (lib) and also add an entry to the Tools menu/project folder (rsc).

I haven't done it yet but I can't see any reason not to combine names to cover the above and show that you have a hybrid install when you do a search.

E.g. company_lib_rsc_package_name

??

[Norm Kirchner]

I am interested to hear how others divide up their distributions.

What is everyones opinion on this?

One of the problems with giving things this kind of standard name, is that what do do you do when 1 package meets two criteria.

Or worse than that, really doesn't fit into the definitions.

Trust me, it's possible.

So I pose this question, does the presence of this identifier really give you any extra value?

Does really a source (NI, NISE, LAVAG, JGCODE) + a descriptive name give you enough?

Also, now that packages can have verbose names different than the file names, does it still make sense to have these abbreviated names that also have things that are in other filterable fields as well?

I'm not so certain that it is.

The list in VIPM is going to get cluttered.... really cluttered because of the amount of packages that are going to be released over time.

So having a few extra abbreviated characters won't provide any information that I would search for when looking for a unique package.

[jgcode]

jgcode, why aren't you?

I just VIPM 3.0 so much I can't let go

As far as categories and tags. Yes! we agree that this is a great feature to have in VIPM. But we don't have it yet.

Cool

As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool).

Amen to that.

I did bring this up at NI Week but no seemed to like it

I should have mentioned this to you!

IMO, I don't think all submissions need this, but my idea is that LAVA should have another level of certification.

A higher level whereby releases would implement the above naming schema, and the code would be more tight and (kinda like NI's Add-on Developer levels) etc...

I would love to see that.

So I pose this question, does the presence of this identifier really give you any extra value?

Does really a source (NI, NISE, LAVAG, JGCODE) + a descriptive name give you enough?

I think a source is a good idea and is required as mentioned above as it would form part of the unique identifier.

As long as other names are controlled by that source then there should be no conflicts in the community.

You could even go as far as registering for a source name (form some governing body) so that for whatever reasons there are no clashes in the future.

Off Topic?

Aside from names there are also going to be cases of installing to the same location - I don't know how that could be controlled?

E.g. I have a make a package that installs LVOOP Accessor Hooks, you make one too - how does VIPM keep track of that?

Installing one will overwrite the files of the other whilst VIPM still thinks its installed.

The only way would be to include it as a conflict package.

[crelf]

So we're agreed that standardized package filenames aren't necessarily a good idea? I think they are within an organization perhaps, but not in the community at large.

As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool).

I think it'd make more sense to have LAVA packages in a LAVA repository - then "LAVA" or "LabVIEW Advanced Virtual Architects" or "lavag.org" or whatever we want would show up in the repository field.

[jgcode]

So we're agreed that standardized package filenames aren't necessarily a good idea? I think they are within an organization perhaps, but not in the community at large.

Oh well am I on my own here?

I like the idea of being able to type rcf in the search box and have all the Right Click Framework packages appear.

This was a standard set somewhere that people have followed and it makes it easier to find things.

Keywords in the package name is handy, especially ones that come down automatically from the VI Package Network.

[crelf]

I like the idea of being able to type rcf in the search box and have all the Right Click Framework packages appear.

I think the functionality of a package is more important to the framework it plugs in to. That said, I don't mind if extra stuff is shown somewhere that's searchable (like the "Get Info" stuff).

[Michael Aivaliotis]

Off Topic?

Aside from names there are also going to be cases of installing to the same location - I don't know how that could be controlled?

E.g. I have a make a package that installs LVOOP Accessor Hooks, you make one too - how does VIPM keep track of that?

Installing one will overwrite the files of the other whilst VIPM still thinks its installed.

The only way would be to include it as a conflict package.

In this specific case, LVOOP Accessor Hooks, I would suggest using a renaming convention (prefix or suffix) for your VIs.

Also, NI has come up with conventions for Add-On developers located here: http://decibel.ni.co...d-on-dev-center

Specifically, here is a doc that explains the recommended folder names for installing your stuff: http://decibel.ni.co...t/docs/DOC-8737

You really need to pay attention to where and how you install your stuff. VIPM 2010 already has all the NI conventions built-in.

I think it'd make more sense to have LAVA packages in a LAVA repository - then "LAVA" or "LabVIEW Advanced Virtual Architects" or "lavag.org" or whatever we want would show up in the repository field.

I assume you mean it's more important to have a LAVA Repository than it is to have a LAVA label in the product or filename. Right?

I agree.

[Ton Plomp]

I don't think we need a tight naming scheme. I think we need an on-topic naming scheme together with some categories and tags.

A guidance might be the Linux development, if you look at the Ubuntu packages set, you see there is a limited list of categories, and I believe a package can fit in two categories.

When doing a search, one just types in what comes to mind 'source control', now the package manager searches through the available packages and returns a sorted list of packages. These can be filtered upon categories. I think there are several ways of sorting, but the first is:

• Popularity
  With VIPM we can use the internet connection to have a database where the popularity of packages is traced. A system would be '+1' for each install '+2' for each package that is installed after 4 weeks. '-1' for each uninstall. This data can be anonymized, or only kept local in the current repository.
• Relevance
  Relevance can be calculated upon, does the search term comes up in the packag name, tag-list or description
• Code standard
• Paid
• Open source
• License

I think the default sort should be 'Popularity', which can be influenced by 'Relevance' (for instance a popularity score with 80, but relevance 5, could be below pop=30, relevance=95).

Ton

[crelf]

I assume you mean it's more important to have a LAVA Repository than it is to have a LAVA label in the product or filename. Right?

I agree.

*exactly*! And then we could talk about how VIPM users can either automatically or manually connect to the repository.

[jgcode]

In this specific case, LVOOP Accessor Hooks, I would suggest using a renaming convention (prefix or suffix) for your VIs.

Also, NI has come up with conventions for Add-On developers located here: http://decibel.ni.co...d-on-dev-center

Specifically, here is a doc that explains the recommended folder names for installing your stuff: http://decibel.ni.co...t/docs/DOC-8737

In this specific case - you can't use a naming convention as you have to install the Hook and name it what NI have called it.

I will check out your links.

[ShaunR]

*exactly*! And then we could talk about how VIPM users can either automatically or manually connect to the repository.

How would you handle the submissions to the LAVA repository that aren't packaged in a VIPM distribution?

[Michael Aivaliotis]

In this specific case - you can't use a naming convention as you have to install the Hook and name it what NI have called it.

Ah, you're right.

VIPM 2010 has a new built-in file counter feature which kicks-in when overwriting duplicate files. This means that when you uninstall a file, it is not removed completely until the file counter goes down to zero. However there is nothing we are doing right now to force an uninstall of a package unless, as you correctly stated, you declare a conflict. Of course you need to know what package to create a conflict for.

One thing to consider is how to restore the original NI VIs. Are you performing a pre-install action to back them up and a post-uninstall action to restore them?

How would you handle the submissions to the LAVA repository that aren't packaged in a VIPM distribution?

Currently LAVA CR accepts submissions as Zip files or Packages. Only packages would be submitted to the LAVA (VIPM compatible) Repository.

[ShaunR]

Currently LAVA CR accepts submissions as Zip files or Packages. Only packages would be submitted to the LAVA (VIPM compatible) Repository.

Hmmm.

Does that mean you would have 2 repostories one for packages and one for zip files? Or do you mean that you will not accept a submission UNLESS it is packaged for VIPM?

[Michael Aivaliotis]

Hmmm.

Does that mean you would have 2 repostories one for packages and one for zip files? Or do you mean that you will not accept a submission UNLESS it is packaged for VIPM?

The LAVA CR Web front-end (what we already have now) accepts Zip files or Packages. This will not change.

We don't have a VIPM compatible LAVA CR repository yet and I don't know if we will ever have one. But I would love to have one and if the LAVA community yells loud enough (hint hint) maybe we will. Who knows

But in this hypothetical future, if we did have a VIPM compatible LAVA CR repository, then only packaged submissions would go into that repository since that is the only format compatible with the VIPM repository. However we would continue accepting Zip files and packages into the LAVA CR Web front-end.

[ShaunR]

The LAVA CR Web front-end (what we already have now) accepts Zip files or Packages. This will not change.

We don't have a VIPM compatible LAVA CR repository yet and I don't know if we will ever have one. But I would love to have one and if the LAVA community yells loud enough (hint hint) maybe we will. Who knows

But in this hypothetical future, if we did have a VIPM compatible LAVA CR repository, then only packaged submissions would go into that repository since that is the only format compatible with the VIPM repository. However we would continue accepting Zip files and packages into the LAVA CR Web front-end.

Sweet. Thanks for clarifying.

[Daklu]

Honest guys, it was just an idle question. I didn't mean to stir up the dust...

I agree tagging, searching, and allowing the user to set up a custom package organization (similar to virtual folders in the project window) in the way that makes sense to them will be more valuable than a standardized (but still cryptic) file name. Another feature that would help me is an info pane on the main window that would show at least the description. Having a modal info dialog is inconvenient.

As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool).

It's been a year since I've submitted anything to the Lava CR. Is there a document explaining suggested install locations and resources? (I created a LAVA palette icon that I think I built into my Interface Framework package. I'll have to see if I can dig it out...)

[jgcode]

One thing to consider is how to restore the original NI VIs. Are you performing a pre-install action to back them up and a post-uninstall action to restore them?

Yes, this is what I do a the moment: for NI VIs I create a backup.zip of the files and install that in a safe place.

I use pre and post uninstall scripts to extract the zip and restore the state of the original VIs on uninstall.

I have some simple templates I use to do this.

I have done preinstall actions in the past (i.e. in the case where the User might want to preserve their hooks) but if an issue occurs then things can go whack, so I find the above much safer.

But, really the User should play it safe and have a backup of their hooks or more correctly everything under <LabVIEW> (I mean really they should be using packages!) so I don't know if that really matters anymore and that the backup.zip is fine.

But I would love to have one and if the LAVA community yells loud enough (hint hint)

This is me yelling.

[Mellroth]

...

We don't have a VIPM compatible LAVA CR repository yet and I don't know if we will ever have one. But I would love to have one and if the LAVA community yells loud enough (hint hint) maybe we will. Who knows

<YELL>I REALLY LIKE THE IDEA OF A LAVA REPOSITORY</YELL>, it would be much easier to find packages using VIPM instead of digging through the CR.

It would also solve the issues of dependencies between LAVA submissions (I don't know if there are any today).

/J

[Daklu]

+1 for a Lava repository.

Found the palette icon I created.

[Michael Aivaliotis]

+1 for a Lava repository.

Found the palette icon I created.

I really like that icon. I vote we use that as the palette category icon.