Deciding on the MacPorts name should happen in one place

[reneeotten]

We currently convert the upstream name to lowercase and/or do other manipulations in multiple locations.

For example, in the MacPortsPythonPackage class there is:

    def _pkgname(self):
        macports_name = self._normalized_macports_name(self.upt_pkg.name)
        return f'{macports_name}'

    @staticmethod
    def _normalized_macports_name(name):
        name = name.lower()
        return f'py-{name}'

    @staticmethod
    def _normalized_macports_folder(name):
        name = name.lower()
        return f'py-{name}'

and after the template-clean up there will be another translation of dependency names

def jinja2_reqformat(self, req):
    return f'py${{python.version}}-{req.name.lower()}'

this should really be only done once and re-used in all the other functions.

[reneeotten]

FYI: since MacPorts requires the name field in the Portfile to be identical to the name of the directory it is in, we probably do not need two separate functions.

[Korusuke]

FYI: since MacPorts requires the name field in the Portfile to be identical to the name of the directory it is in, we probably do not need two separate functions.

I don't think this holds true for perl and ruby ports. Refer this link.

We can reduce the places where manipulation takes place but I guess no. of functions should stay same for consistency across different upstreams.

I tried reducing some manipulations by making the _normalized_macports_folder depend on _normalized_macports_name but as the former is a static method it cannot access the later by self. and if I don't keep it static method then I believe that would lead to issue in the latest recursive packaging PR where finally we are not creating instance as _normalized_macports_folder is a static method.

I will try to reduce no. of different places where things are happening.

Any thoughts?

[reneeotten]

FYI: since MacPorts requires the name field in the Portfile to be identical to the name of the directory it is in, we probably do not need two separate functions.

I don't think this holds true for perl and ruby ports.

well, since the PG for these ports uses a *.setup method, there is actually no name field in the Portfile. If there would be a name field the requirement is that it's the same as the directory name. So technically you're correct that my comment applies to Python ports only.

I have no problem with -for consistency reasons- keeping the number of functions the same so that it can handle all the different frontends. Point is that how to translate the name (i.e., convert to all lower case, do replace('::', '-'), should be ideally done in one place and then other functions can manipulate that name by adding "py-" or whatever.

I can't comment off-hand about the "staticmethod" business, that just needs some trying and testing.

[jmroot]

The setup procedures do set the name option (it's a required option for all ports).

[reneeotten]

thanks @jmroot and you're, of course, completely right.

What I meant to say is that in the context of upt only for Python ports there is a direct correspondence to what is set in the name field in the Portfile and the directory-name of the port. For the other categories, the "name" that is set in the Portfile's *.setup field does not need to be the same as the port-directory (but the name that comes out of the setup procedure does).

[jmroot]

Sure, those aren't necessarily the same. Hopefully the setup procs accept the upstream-preferred name when that's different to the port name.