another distutils question

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Eric S. Johansson

    #1

    another distutils question

    is there anyway I can, in a setup.py file, set and internal equivalent
    to the '--install-scripts' commandline option?

    script installation directory but I don't want on the command line where
    things can go horribly wrong if the user forgets. I would like to
    create a new default setting for this commandline option as well as a
    couple of other such as the data default directory.

    --- eric

  • Keith Perkins

    #2
    Re: another distutils question

    On Fri, 29 Sep 2006 13:53:46 -0400, Eric S. Johansson wrote:
    is there anyway I can, in a setup.py file, set and internal equivalent
    to the '--install-scripts' commandline option?
    >
    script installation directory but I don't want on the command line where
    things can go horribly wrong if the user forgets. I would like to
    create a new default setting for this commandline option as well as a
    couple of other such as the data default directory.
    >
    --- eric
    On a similar note , I have another question about distutils and data files.
    I have a little program that uses a txt file to store data, and it works
    fine running it in it's own folder, if I install through distutils, using
    sudo to get it to write to the site-packages folder (which root owns), it
    installs the data file so that it is owned by root, and not by me, so
    that the data file can't be written to (although the script can read it).
    Do I need to run a post install script, or add something to setup.py file
    to chown the file or am I doing something wrong? There doesn't seem to be
    anything on this in the docs.
    Thanks in advance,
    Keith

    Comment

    • Robert Kern

      #3
      Re: another distutils question

      Keith Perkins wrote:
      On a similar note , I have another question about distutils and data files.
      I have a little program that uses a txt file to store data, and it works
      fine running it in it's own folder, if I install through distutils, using
      sudo to get it to write to the site-packages folder (which root owns), it
      installs the data file so that it is owned by root, and not by me, so
      that the data file can't be written to (although the script can read it).
      Do I need to run a post install script, or add something to setup.py file
      to chown the file or am I doing something wrong? There doesn't seem to be
      anything on this in the docs.
      There's nothing in distutils specifically that will let you do this. The root
      user will have to chown/chgrp/chmod/chwhatever the package that you installed
      manually.

      You shouldn't use package data for things that are going to be modified.
      Instead, use a directory like ~/.myscript/ or something else.

      --
      Robert Kern

      "I have come to believe that the whole world is an enigma, a harmless enigma
      that is made terrible by our own mad attempt to interpret it as though it had
      an underlying truth."
      -- Umberto Eco

      Comment

      • Keith Perkins

        #4
        Re: another distutils question

        On Fri, 29 Sep 2006 18:57:12 -0500, Robert Kern wrote:
        Keith Perkins wrote:
        >
        >On a similar note , I have another question about distutils and data files.
        >I have a little program that uses a txt file to store data, and it works
        >fine running it in it's own folder, if I install through distutils, using
        >sudo to get it to write to the site-packages folder (which root owns), it
        >installs the data file so that it is owned by root, and not by me, so
        >that the data file can't be written to (although the script can read it).
        >Do I need to run a post install script, or add something to setup.py file
        >to chown the file or am I doing something wrong? There doesn't seem to be
        >anything on this in the docs.
        >
        There's nothing in distutils specifically that will let you do this. The root
        user will have to chown/chgrp/chmod/chwhatever the package that you installed
        manually.
        >
        You shouldn't use package data for things that are going to be modified.
        Instead, use a directory like ~/.myscript/ or something else.
        I did install it in ~/.script/data.txt, and distutils set the
        user/group as root. Is it impossible to install this with distutils?
        Since I'm running setup as root, should I just add a class or method to
        chown the datafolder/file to the installer. Should I use autotools
        instead? I haven't looked into eggs yet would that be a better choice? The
        data file is something that is necessary for the program (it reads it and
        prints out a random line--the whole idea of the script)if that's all I
        wanted it to do I wouldn't have any problems--I could even include it as a
        list in the script file, but I would like the user to be able to add other
        data.
        Thanks,
        Keith

        Comment

        • Robert Kern

          #5
          Re: another distutils question

          Keith Perkins wrote:
          I did install it in ~/.script/data.txt, and distutils set the
          user/group as root. Is it impossible to install this with distutils?
          Since I'm running setup as root, should I just add a class or method to
          chown the datafolder/file to the installer. Should I use autotools
          instead? I haven't looked into eggs yet would that be a better choice? The
          data file is something that is necessary for the program (it reads it and
          prints out a random line--the whole idea of the script)if that's all I
          wanted it to do I wouldn't have any problems--I could even include it as a
          list in the script file, but I would like the user to be able to add other
          data.
          Don't use "setup.py install" to install that directory. Imagine a case where the
          root user installs the package for everyone on the system to use. How do the
          multiple users get ~/.script/?

          Instead, include the default data inside the package (read-only to non-root
          users). Then allow the script itself to create the directory the first time it
          is run (read-write, and it should then automatically be accessible to the user
          that ran the script). You might also add a command-line option to *only* install
          that directory.

          --
          Robert Kern

          "I have come to believe that the whole world is an enigma, a harmless enigma
          that is made terrible by our own mad attempt to interpret it as though it had
          an underlying truth."
          -- Umberto Eco

          Comment

          • Eric S. Johansson

            #6
            Re: another distutils question

            Keith Perkins wrote:
            >
            On a similar note , I have another question about distutils and data files.
            I have a little program that uses a txt file to store data, and it works
            fine running it in it's own folder, if I install through distutils, using
            sudo to get it to write to the site-packages folder (which root owns), it
            installs the data file so that it is owned by root, and not by me, so
            that the data file can't be written to (although the script can read it).
            Do I need to run a post install script, or add something to setup.py file
            to chown the file or am I doing something wrong? There doesn't seem to be
            anything on this in the docs.
            1: as pointed out, site-packages is for code only :-)

            2: you will need a post processing script.

            here is an example of distutils abuse that may help a little bit. I
            needed to collect files from a file hierarchy and one other place in the
            source directory then stuff them in the right place in the production
            directory. Since the pattern was unpredictable, I built a method to
            accumulate data file references.

            the solution is a bit more hard coded than I like but it gets the job
            done for now. as I need to improve it, I'll fix it.

            def expand_hierarch y(starting_poin t, data_files):
            dir_files = os.walk(startin g_point)

            for (path, name, files) in dir_files:
            x = os.path.basenam e(path)
            if x != 'CVS':
            clean_files = [ os.path.join(pa th,item) \
            for item in files \
            if (clean_test(ite m)) ]
            data_files.appe nd((cr_paths%pa th,clean_files) )

            return data_files

            setup(...
            data_files=expa nd_hierarchy("w eb-ui",
            [(cr_paths%'etc' ,

            ['ancillary/baseline_config uration']),
            ],
            )


            to solve the file perms problem you run something after setup. how you
            associate perms/ownership with a file is up to you. It might work to
            use data_files to enumerate files you apply the common perms/owernship.
            then special case what you need to.

            hope this gives you some useful ideas.

            --- eric

            Comment

            • Eric S. Johansson

              #7
              Re: another distutils question

              Robert Kern wrote:
              Instead, include the default data inside the package (read-only to non-root
              users). Then allow the script itself to create the directory the first time it
              is run (read-write, and it should then automatically be accessible to the user
              that ran the script). You might also add a command-line option to *only* install
              that directory.
              I would be okay with a package/data/... arrangement if and only if the
              data within that directory was read only and only changed when the
              package changed it. System specific changes would be in a system copy
              of the configuration file and user specific changes would be a user copy.

              If you create a configuration system which uses a union of all three
              configuration files, you eliminate unnecessary replication of
              configuration values, minimize changes necessary when the baseline
              configuration file changes, and you also have the opportunity to
              control scope of configuration variables. I.e. some that are only
              changed in the system config file.

              I have an application dependent version of this I've been using for the
              past three years and, it's really nice. It lets me mostly ignore the
              configuration files and focus on what I'm trying to solve.

              --- eric

              Comment

              • Keith Perkins

                #8
                Re: another distutils question

                Thanks everyone, for your answers. They've been very helpful.
                Keith

                Comment

                Working...